projetos
Sobre mim
Contato
Portfolio • Product Design (UX)
Oiê! Eu sou a
Isabella Bello.
Transformo experiências humanas em soluções digitais desde 2018.
Ver projetos
Contato
UX/UI · setor público · acessibilidade
IDEA 2.0
Evolução do handoff e incorporação de acessibilidade
CLiente
Ministério Público do Estado da Bahia
Ano
2026
Área
UX/UI
Mais detalhes
01
Contexto
O projeto consistiu na estruturação de uma estratégia de acessibilidade para a plataforma IDEA 2.0, em desenvolvimento para o Ministério Público do Estado da Bahia (MPBA). O sistema, utilizado internamente por membros e servidores da instituição, apresentava inconsistências visuais, falta de padronização e ausência de requisitos de acessibilidade integrados ao fluxo de desenvolvimento.
Meu papel no projeto foi de pesquisadora e designer de experiência, atuando na condução de auditorias, pesquisas com o time técnico e proposição de melhorias para o Design System e o processo de handoff.
Ferramentas utilizadas: Figma, Google Forms.
02
Desafio
O principal desafio era garantir que a acessibilidade deixasse de ser um esforço individual e passasse a ser um critério de qualidade integrado ao fluxo de desenvolvimento da plataforma IDEA 2.0 do MPBA.
Para o time de desenvolvimento, a dificuldade estava em aplicar acessibilidade sem diretrizes claras, com alta complexidade cognitiva e baixa previsibilidade de esforço. Para a instituição, o problema se traduzia em retrabalho técnico, inconsistência na experiência do usuário e risco de não conformidade com padrões legais (eMAG/WCAG), especialmente relevante para um órgão público.
Além disso, a plataforma enfrentava problemas estruturais de Design: guia de estilos desatualizado, componentes inconsistentes entre telas, falta de documentação de acessibilidade e ausência de definição de responsividade.
03
Processo
A investigação foi conduzida em múltiplas frentes, combinando análises técnicas e pesquisas com usuários internos do MPBA.
Auditoria de contraste
Realizei uma auditoria de contraste de cores utilizando a ferramenta Juicy Studio, avaliando todos os tokens do Design System e componentes em contexto real, com base nos critérios WCAG 2.0 (níveis AA e AAA). Foram identificadas combinações com contraste insuficiente em textos, botões, inputs, checkboxes, chips, alerts e demais elementos, resultando em um plano de correção com novas cores para os tokens — como o escurecimento do Product/Blue de #0F73B2 para #0A5D91 e do Neutral/Black de #444A55 para #333333.
Pesquisa sobre responsividade
Analisei mais de 2,2 milhões de acessos ao sistema anterior (IDEA 1.0), coletados entre julho de 2025 e julho de 2026, para definir uma estratégia de responsividade baseada em dados reais de uso pelos servidores do MPBA. A análise revelou que 60% dos acessos concentram-se em resoluções de notebook, embora o handoff anterior contemplasse apenas 26,5% desse cenário. Com base nisso, defini quatro breakpoints priorizados: 1920×1080 (XL), 1366×768 (LG), 768×1024 (SM) e 390×844 (XS) — este último com menos de 1% dos acessos, indicando que o uso mobile não era prioritário para o contexto institucional.
Pesquisa com desenvolvedores — Handoff de acessibilidade
Apliquei um formulário qualitativo com 4 desenvolvedores front-end (de um total de 8) para avaliar um modelo de handoff de acessibilidade proposto. Os resultados indicaram que, apesar da alta clareza percebida (média 4,5/5), apenas metade dos participantes afirmou conseguir implementar acessibilidade plenamente com base na documentação. Identifiquei também uma tensão entre redução de dúvidas e impacto no tempo de desenvolvimento: 3 de 4 participantes indicaram que o handoff poderia tornar a implementação mais lenta.
Grupo focal com desenvolvedores
Realizei um grupo focal moderado para aprofundar a compreensão sobre o fluxo real de desenvolvimento do IDEA 2.0 e como a acessibilidade é considerada nesse processo. As descobertas foram contundentes:
- Acessibilidade não está integrada ao fluxo: é aplicada tardiamente, após a implementação funcional, o que aumenta o retrabalho técnico.
- Não é tratada como critério de qualidade: não há validação estruturada em QA nem critérios de aceite definidos.
- Depende de esforço individual: desenvolvedores precisam interpretar o que deve ser feito sem direcionamento claro, em um cenário já complexo.
A partir desses achados, propus três direções de evolução: antecipar (trazer acessibilidade para o planejamento), formalizar (incluir como critério de aceite e validação em QA) e facilitar (centralizar documentação e criar componentes acessíveis reutilizáveis).
04
Resultado
A solução desenvolvida contemplou entregas em múltiplas camadas para o IDEA 2.0 do MPBA:
- Definição de breakpoints de responsividade: com base em dados reais de uso dos servidores, alinhando Design e Desenvolvimento sobre quais tamanhos de tela priorizar.
- Modelo de handoff de acessibilidade: documentação com requisitos de foco, tabulação, semântica HTML, área de clique e texto alternativo, validado com o time técnico.
- Proposta de biblioteca de componentes acessíveis: em parceria com desenvolvimento, para reduzir decisões repetitivas e aumentar consistência.
- Proposta de atualização do Guia de Estilos: revisão de tokens de cor com base na auditoria de contraste, garantindo conformidade com níveis AA e AAA em conformidade com a auditoria de acessibilidade conduzida por mim.
Os impactos esperados foram:
- Redução de desalinhamentos entre Design e Desenvolvimento, com handoff baseado em dados e validado com o time.
- Maior previsibilidade das entregas, ao incluir acessibilidade no planejamento e na estimativa de esforço.
- Base para evolução do Design System, com tokens revisados e documentação centralizada.
- Mudança de cultura: a acessibilidade passou a ser tratada como responsabilidade compartilhada, não como esforço individual, no contexto do MPBA.
Imagem A e B: Telas representando o Handoff de acessibilidade e resposividade.
05
Aprendizado
O projeto reforçou que acessibilidade não se resolve apenas com documentação. Por mais clara que uma diretriz seja, sua efetividade depende de estar integrada ao fluxo de trabalho, com critérios de aceite claros, validação em QA e componentes reutilizáveis que reduzam o esforço cognitivo do time.
Outro aprendizado importante foi que dados de uso são fundamentais para decisões de design. A análise de mais de 2 milhões de acessos ao sistema anterior do MPBA evitou o desenvolvimento de soluções para cenários irrelevantes e direcionou o esforço para o que realmente importa: a experiência em notebooks corporativos.
Por fim, ficou evidente que a evolução do Design System é uma alavanca para escalabilidade e qualidade. A transição de um modelo de arquivos únicos no Figma para uma estrutura organizada por páginas e documentação centralizada não é apenas uma melhoria operacional — é uma condição para que o produto evolua com consistência e segurança, especialmente em um contexto institucional como o do Ministério Público.
© 2026 · Isabella Smaniotto Bello
UX/UI · setor público · acessibilidade
IDEA 2.0
Evolução do handoff e incorporação de acessibilidade
CLiente
Ministério Público do Estado da Bahia
Ano
2026
Área
UX/UI
Mais detalhes
01
Contexto
O projeto consistiu na estruturação de uma estratégia de acessibilidade para a plataforma IDEA 2.0, em desenvolvimento para o Ministério Público do Estado da Bahia (MPBA). O sistema, utilizado internamente por membros e servidores da instituição, apresentava inconsistências visuais, falta de padronização e ausência de requisitos de acessibilidade integrados ao fluxo de desenvolvimento.
Meu papel no projeto foi de pesquisadora e designer de experiência, atuando na condução de auditorias, pesquisas com o time técnico e proposição de melhorias para o Design System e o processo de handoff.
Ferramentas utilizadas: Figma, Google Forms.
02
Desafio
O principal desafio era garantir que a acessibilidade deixasse de ser um esforço individual e passasse a ser um critério de qualidade integrado ao fluxo de desenvolvimento da plataforma IDEA 2.0 do MPBA.
Para o time de desenvolvimento, a dificuldade estava em aplicar acessibilidade sem diretrizes claras, com alta complexidade cognitiva e baixa previsibilidade de esforço. Para a instituição, o problema se traduzia em retrabalho técnico, inconsistência na experiência do usuário e risco de não conformidade com padrões legais (eMAG/WCAG), especialmente relevante para um órgão público.
Além disso, a plataforma enfrentava problemas estruturais de Design: guia de estilos desatualizado, componentes inconsistentes entre telas, falta de documentação de acessibilidade e ausência de definição de responsividade.
03
Processo
A investigação foi conduzida em múltiplas frentes, combinando análises técnicas e pesquisas com usuários internos do MPBA.
Auditoria de contraste
Realizei uma auditoria de contraste de cores utilizando a ferramenta Juicy Studio, avaliando todos os tokens do Design System e componentes em contexto real, com base nos critérios WCAG 2.0 (níveis AA e AAA). Foram identificadas combinações com contraste insuficiente em textos, botões, inputs, checkboxes, chips, alerts e demais elementos, resultando em um plano de correção com novas cores para os tokens — como o escurecimento do Product/Blue de #0F73B2 para #0A5D91 e do Neutral/Black de #444A55 para #333333.
Pesquisa sobre responsividade
Analisei mais de 2,2 milhões de acessos ao sistema anterior (IDEA 1.0), coletados entre julho de 2025 e julho de 2026, para definir uma estratégia de responsividade baseada em dados reais de uso pelos servidores do MPBA. A análise revelou que 60% dos acessos concentram-se em resoluções de notebook, embora o handoff anterior contemplasse apenas 26,5% desse cenário. Com base nisso, defini quatro breakpoints priorizados: 1920×1080 (XL), 1366×768 (LG), 768×1024 (SM) e 390×844 (XS) — este último com menos de 1% dos acessos, indicando que o uso mobile não era prioritário para o contexto institucional.
Pesquisa com desenvolvedores — Handoff de acessibilidade
Apliquei um formulário qualitativo com 4 desenvolvedores front-end (de um total de 8) para avaliar um modelo de handoff de acessibilidade proposto. Os resultados indicaram que, apesar da alta clareza percebida (média 4,5/5), apenas metade dos participantes afirmou conseguir implementar acessibilidade plenamente com base na documentação. Identifiquei também uma tensão entre redução de dúvidas e impacto no tempo de desenvolvimento: 3 de 4 participantes indicaram que o handoff poderia tornar a implementação mais lenta.
Grupo focal com desenvolvedores
Realizei um grupo focal moderado para aprofundar a compreensão sobre o fluxo real de desenvolvimento do IDEA 2.0 e como a acessibilidade é considerada nesse processo. As descobertas foram contundentes:
- Acessibilidade não está integrada ao fluxo: é aplicada tardiamente, após a implementação funcional, o que aumenta o retrabalho técnico.
- Não é tratada como critério de qualidade: não há validação estruturada em QA nem critérios de aceite definidos.
- Depende de esforço individual: desenvolvedores precisam interpretar o que deve ser feito sem direcionamento claro, em um cenário já complexo.
A partir desses achados, propus três direções de evolução: antecipar (trazer acessibilidade para o planejamento), formalizar (incluir como critério de aceite e validação em QA) e facilitar (centralizar documentação e criar componentes acessíveis reutilizáveis).
04
Resultado
A solução desenvolvida contemplou entregas em múltiplas camadas para o IDEA 2.0 do MPBA:
- Definição de breakpoints de responsividade: com base em dados reais de uso dos servidores, alinhando Design e Desenvolvimento sobre quais tamanhos de tela priorizar.
- Modelo de handoff de acessibilidade: documentação com requisitos de foco, tabulação, semântica HTML, área de clique e texto alternativo, validado com o time técnico.
- Proposta de biblioteca de componentes acessíveis: em parceria com desenvolvimento, para reduzir decisões repetitivas e aumentar consistência.
- Proposta de atualização do Guia de Estilos: revisão de tokens de cor com base na auditoria de contraste, garantindo conformidade com níveis AA e AAA em conformidade com a auditoria de acessibilidade conduzida por mim.
Os impactos esperados foram:
- Redução de desalinhamentos entre Design e Desenvolvimento, com handoff baseado em dados e validado com o time.
- Maior previsibilidade das entregas, ao incluir acessibilidade no planejamento e na estimativa de esforço.
- Base para evolução do Design System, com tokens revisados e documentação centralizada.
- Mudança de cultura: a acessibilidade passou a ser tratada como responsabilidade compartilhada, não como esforço individual, no contexto do MPBA.
Imagem A e B: Telas representando o Handoff de acessibilidade e resposividade.
05
Aprendizado
O projeto reforçou que acessibilidade não se resolve apenas com documentação. Por mais clara que uma diretriz seja, sua efetividade depende de estar integrada ao fluxo de trabalho, com critérios de aceite claros, validação em QA e componentes reutilizáveis que reduzam o esforço cognitivo do time.
Outro aprendizado importante foi que dados de uso são fundamentais para decisões de design. A análise de mais de 2 milhões de acessos ao sistema anterior do MPBA evitou o desenvolvimento de soluções para cenários irrelevantes e direcionou o esforço para o que realmente importa: a experiência em notebooks corporativos.
Por fim, ficou evidente que a evolução do Design System é uma alavanca para escalabilidade e qualidade. A transição de um modelo de arquivos únicos no Figma para uma estrutura organizada por páginas e documentação centralizada não é apenas uma melhoria operacional — é uma condição para que o produto evolua com consistência e segurança, especialmente em um contexto institucional como o do Ministério Público.
© 2026 · Isabella Smaniotto Bello
UX/UI · setor público · acessibilidade
IDEA 2.0
Evolução do handoff e incorporação de acessibilidade
CLiente
Ministério Público do Estado da Bahia
Ano
2026
Área
UX/UI
Mais detalhes
01
Contexto
O projeto consistiu na estruturação de uma estratégia de acessibilidade para a plataforma IDEA 2.0, em desenvolvimento para o Ministério Público do Estado da Bahia (MPBA). O sistema, utilizado internamente por membros e servidores da instituição, apresentava inconsistências visuais, falta de padronização e ausência de requisitos de acessibilidade integrados ao fluxo de desenvolvimento.
Meu papel no projeto foi de pesquisadora e designer de experiência, atuando na condução de auditorias, pesquisas com o time técnico e proposição de melhorias para o Design System e o processo de handoff.
Ferramentas utilizadas: Figma, Google Forms.
02
Desafio
O principal desafio era garantir que a acessibilidade deixasse de ser um esforço individual e passasse a ser um critério de qualidade integrado ao fluxo de desenvolvimento da plataforma IDEA 2.0 do MPBA.
Para o time de desenvolvimento, a dificuldade estava em aplicar acessibilidade sem diretrizes claras, com alta complexidade cognitiva e baixa previsibilidade de esforço. Para a instituição, o problema se traduzia em retrabalho técnico, inconsistência na experiência do usuário e risco de não conformidade com padrões legais (eMAG/WCAG), especialmente relevante para um órgão público.
Além disso, a plataforma enfrentava problemas estruturais de Design: guia de estilos desatualizado, componentes inconsistentes entre telas, falta de documentação de acessibilidade e ausência de definição de responsividade.
03
Processo
A investigação foi conduzida em múltiplas frentes, combinando análises técnicas e pesquisas com usuários internos do MPBA.
Auditoria de contraste
Realizei uma auditoria de contraste de cores utilizando a ferramenta Juicy Studio, avaliando todos os tokens do Design System e componentes em contexto real, com base nos critérios WCAG 2.0 (níveis AA e AAA). Foram identificadas combinações com contraste insuficiente em textos, botões, inputs, checkboxes, chips, alerts e demais elementos, resultando em um plano de correção com novas cores para os tokens — como o escurecimento do Product/Blue de #0F73B2 para #0A5D91 e do Neutral/Black de #444A55 para #333333.
Pesquisa sobre responsividade
Analisei mais de 2,2 milhões de acessos ao sistema anterior (IDEA 1.0), coletados entre julho de 2025 e julho de 2026, para definir uma estratégia de responsividade baseada em dados reais de uso pelos servidores do MPBA. A análise revelou que 60% dos acessos concentram-se em resoluções de notebook, embora o handoff anterior contemplasse apenas 26,5% desse cenário. Com base nisso, defini quatro breakpoints priorizados: 1920×1080 (XL), 1366×768 (LG), 768×1024 (SM) e 390×844 (XS) — este último com menos de 1% dos acessos, indicando que o uso mobile não era prioritário para o contexto institucional.
Pesquisa com desenvolvedores — Handoff de acessibilidade
Apliquei um formulário qualitativo com 4 desenvolvedores front-end (de um total de 8) para avaliar um modelo de handoff de acessibilidade proposto. Os resultados indicaram que, apesar da alta clareza percebida (média 4,5/5), apenas metade dos participantes afirmou conseguir implementar acessibilidade plenamente com base na documentação. Identifiquei também uma tensão entre redução de dúvidas e impacto no tempo de desenvolvimento: 3 de 4 participantes indicaram que o handoff poderia tornar a implementação mais lenta.
Grupo focal com desenvolvedores
Realizei um grupo focal moderado para aprofundar a compreensão sobre o fluxo real de desenvolvimento do IDEA 2.0 e como a acessibilidade é considerada nesse processo. As descobertas foram contundentes:
- Acessibilidade não está integrada ao fluxo: é aplicada tardiamente, após a implementação funcional, o que aumenta o retrabalho técnico.
- Não é tratada como critério de qualidade: não há validação estruturada em QA nem critérios de aceite definidos.
- Depende de esforço individual: desenvolvedores precisam interpretar o que deve ser feito sem direcionamento claro, em um cenário já complexo.
A partir desses achados, propus três direções de evolução: antecipar (trazer acessibilidade para o planejamento), formalizar (incluir como critério de aceite e validação em QA) e facilitar (centralizar documentação e criar componentes acessíveis reutilizáveis).
04
Resultado
A solução desenvolvida contemplou entregas em múltiplas camadas para o IDEA 2.0 do MPBA:
- Definição de breakpoints de responsividade: com base em dados reais de uso dos servidores, alinhando Design e Desenvolvimento sobre quais tamanhos de tela priorizar.
- Modelo de handoff de acessibilidade: documentação com requisitos de foco, tabulação, semântica HTML, área de clique e texto alternativo, validado com o time técnico.
- Proposta de biblioteca de componentes acessíveis: em parceria com desenvolvimento, para reduzir decisões repetitivas e aumentar consistência.
- Proposta de atualização do Guia de Estilos: revisão de tokens de cor com base na auditoria de contraste, garantindo conformidade com níveis AA e AAA em conformidade com a auditoria de acessibilidade conduzida por mim.
Os impactos esperados foram:
- Redução de desalinhamentos entre Design e Desenvolvimento, com handoff baseado em dados e validado com o time.
- Maior previsibilidade das entregas, ao incluir acessibilidade no planejamento e na estimativa de esforço.
- Base para evolução do Design System, com tokens revisados e documentação centralizada.
- Mudança de cultura: a acessibilidade passou a ser tratada como responsabilidade compartilhada, não como esforço individual, no contexto do MPBA.
Imagem A e B: Telas representando o Handoff de acessibilidade e resposividade.
05
Aprendizado
O projeto reforçou que acessibilidade não se resolve apenas com documentação. Por mais clara que uma diretriz seja, sua efetividade depende de estar integrada ao fluxo de trabalho, com critérios de aceite claros, validação em QA e componentes reutilizáveis que reduzam o esforço cognitivo do time.
Outro aprendizado importante foi que dados de uso são fundamentais para decisões de design. A análise de mais de 2 milhões de acessos ao sistema anterior do MPBA evitou o desenvolvimento de soluções para cenários irrelevantes e direcionou o esforço para o que realmente importa: a experiência em notebooks corporativos.
Por fim, ficou evidente que a evolução do Design System é uma alavanca para escalabilidade e qualidade. A transição de um modelo de arquivos únicos no Figma para uma estrutura organizada por páginas e documentação centralizada não é apenas uma melhoria operacional — é uma condição para que o produto evolua com consistência e segurança, especialmente em um contexto institucional como o do Ministério Público.
© 2026 · Isabella Smaniotto Bello
UX/UI · setor público · acessibilidade
IDEA 2.0
Evolução do handoff e incorporação de acessibilidade
CLiente
Ministério Público do Estado da Bahia
Ano
2026
Área
UX/UI
Mais detalhes
01
Contexto
O projeto consistiu na estruturação de uma estratégia de acessibilidade para a plataforma IDEA 2.0, em desenvolvimento para o Ministério Público do Estado da Bahia (MPBA). O sistema, utilizado internamente por membros e servidores da instituição, apresentava inconsistências visuais, falta de padronização e ausência de requisitos de acessibilidade integrados ao fluxo de desenvolvimento.
Meu papel no projeto foi de pesquisadora e designer de experiência, atuando na condução de auditorias, pesquisas com o time técnico e proposição de melhorias para o Design System e o processo de handoff.
Ferramentas utilizadas: Figma, Google Forms.
02
Desafio
O principal desafio era garantir que a acessibilidade deixasse de ser um esforço individual e passasse a ser um critério de qualidade integrado ao fluxo de desenvolvimento da plataforma IDEA 2.0 do MPBA.
Para o time de desenvolvimento, a dificuldade estava em aplicar acessibilidade sem diretrizes claras, com alta complexidade cognitiva e baixa previsibilidade de esforço. Para a instituição, o problema se traduzia em retrabalho técnico, inconsistência na experiência do usuário e risco de não conformidade com padrões legais (eMAG/WCAG), especialmente relevante para um órgão público.
Além disso, a plataforma enfrentava problemas estruturais de Design: guia de estilos desatualizado, componentes inconsistentes entre telas, falta de documentação de acessibilidade e ausência de definição de responsividade.
03
Processo
A investigação foi conduzida em múltiplas frentes, combinando análises técnicas e pesquisas com usuários internos do MPBA.
Auditoria de contraste
Realizei uma auditoria de contraste de cores utilizando a ferramenta Juicy Studio, avaliando todos os tokens do Design System e componentes em contexto real, com base nos critérios WCAG 2.0 (níveis AA e AAA). Foram identificadas combinações com contraste insuficiente em textos, botões, inputs, checkboxes, chips, alerts e demais elementos, resultando em um plano de correção com novas cores para os tokens — como o escurecimento do Product/Blue de #0F73B2 para #0A5D91 e do Neutral/Black de #444A55 para #333333.
Pesquisa sobre responsividade
Analisei mais de 2,2 milhões de acessos ao sistema anterior (IDEA 1.0), coletados entre julho de 2025 e julho de 2026, para definir uma estratégia de responsividade baseada em dados reais de uso pelos servidores do MPBA. A análise revelou que 60% dos acessos concentram-se em resoluções de notebook, embora o handoff anterior contemplasse apenas 26,5% desse cenário. Com base nisso, defini quatro breakpoints priorizados: 1920×1080 (XL), 1366×768 (LG), 768×1024 (SM) e 390×844 (XS) — este último com menos de 1% dos acessos, indicando que o uso mobile não era prioritário para o contexto institucional.
Pesquisa com desenvolvedores — Handoff de acessibilidade
Apliquei um formulário qualitativo com 4 desenvolvedores front-end (de um total de 8) para avaliar um modelo de handoff de acessibilidade proposto. Os resultados indicaram que, apesar da alta clareza percebida (média 4,5/5), apenas metade dos participantes afirmou conseguir implementar acessibilidade plenamente com base na documentação. Identifiquei também uma tensão entre redução de dúvidas e impacto no tempo de desenvolvimento: 3 de 4 participantes indicaram que o handoff poderia tornar a implementação mais lenta.
Grupo focal com desenvolvedores
Realizei um grupo focal moderado para aprofundar a compreensão sobre o fluxo real de desenvolvimento do IDEA 2.0 e como a acessibilidade é considerada nesse processo. As descobertas foram contundentes:
- Acessibilidade não está integrada ao fluxo: é aplicada tardiamente, após a implementação funcional, o que aumenta o retrabalho técnico.
- Não é tratada como critério de qualidade: não há validação estruturada em QA nem critérios de aceite definidos.
- Depende de esforço individual: desenvolvedores precisam interpretar o que deve ser feito sem direcionamento claro, em um cenário já complexo.
A partir desses achados, propus três direções de evolução: antecipar (trazer acessibilidade para o planejamento), formalizar (incluir como critério de aceite e validação em QA) e facilitar (centralizar documentação e criar componentes acessíveis reutilizáveis).
04
Resultado
A solução desenvolvida contemplou entregas em múltiplas camadas para o IDEA 2.0 do MPBA:
- Definição de breakpoints de responsividade: com base em dados reais de uso dos servidores, alinhando Design e Desenvolvimento sobre quais tamanhos de tela priorizar.
- Modelo de handoff de acessibilidade: documentação com requisitos de foco, tabulação, semântica HTML, área de clique e texto alternativo, validado com o time técnico.
- Proposta de biblioteca de componentes acessíveis: em parceria com desenvolvimento, para reduzir decisões repetitivas e aumentar consistência.
- Proposta de atualização do Guia de Estilos: revisão de tokens de cor com base na auditoria de contraste, garantindo conformidade com níveis AA e AAA em conformidade com a auditoria de acessibilidade conduzida por mim.
Os impactos esperados foram:
- Redução de desalinhamentos entre Design e Desenvolvimento, com handoff baseado em dados e validado com o time.
- Maior previsibilidade das entregas, ao incluir acessibilidade no planejamento e na estimativa de esforço.
- Base para evolução do Design System, com tokens revisados e documentação centralizada.
- Mudança de cultura: a acessibilidade passou a ser tratada como responsabilidade compartilhada, não como esforço individual, no contexto do MPBA.
Imagem A e B: Telas representando o Handoff de acessibilidade e resposividade.
05
Aprendizado
O projeto reforçou que acessibilidade não se resolve apenas com documentação. Por mais clara que uma diretriz seja, sua efetividade depende de estar integrada ao fluxo de trabalho, com critérios de aceite claros, validação em QA e componentes reutilizáveis que reduzam o esforço cognitivo do time.
Outro aprendizado importante foi que dados de uso são fundamentais para decisões de design. A análise de mais de 2 milhões de acessos ao sistema anterior do MPBA evitou o desenvolvimento de soluções para cenários irrelevantes e direcionou o esforço para o que realmente importa: a experiência em notebooks corporativos.
Por fim, ficou evidente que a evolução do Design System é uma alavanca para escalabilidade e qualidade. A transição de um modelo de arquivos únicos no Figma para uma estrutura organizada por páginas e documentação centralizada não é apenas uma melhoria operacional — é uma condição para que o produto evolua com consistência e segurança, especialmente em um contexto institucional como o do Ministério Público.
© 2026 · Isabella Smaniotto Bello