 |
| Bellacosa Mainframe e o web design para programadores cobol |
☕ Um Café no Bellacosa Mainframe
Web Design entre os Mortos — Quando a Interface Caiu e o Sistema Continuou Caminhando
O relógio do CPD marcava 02h17.
As luzes fluorescentes piscavam sobre os corredores vazios. No fundo da sala, um terminal permanecia ligado, exibindo uma tela que nenhum operador lembrava ter aberto:
SYSTEM STATUS: ONLINE
USER EXPERIENCE: CRITICAL
INTERFACE INTEGRITY: 34%
BACK-END ACTIVITY: UNKNOWN
Ao lado do teclado, uma caneca de café ainda soltava fumaça.
Isso significava que alguém estivera ali há pouco tempo.
Ou alguma coisa.
O jovem programador COBOL aproximou-se lentamente. Era seu primeiro plantão noturno. Ele conhecia IDENTIFICATION DIVISION, começava a entender WORKING-STORAGE SECTION e já havia descoberto que uma vírgula colocada no lugar errado podia transformar um programa simples em uma investigação criminal.
Mas naquela noite o problema não estava no COBOL.
O problema estava na interface.
Ela parecia bonita. Moderna. Elegante. Possuía botões arredondados, cores harmoniosas, ícones bem desenhados e animações suaves.
Porém ninguém conseguia utilizá-la.
Os usuários estavam perdidos. Os pedidos desapareciam. Os formulários falhavam. As mensagens de erro não explicavam nada. A aplicação funcionava perfeitamente durante as apresentações, mas entrava em colapso quando encontrava pessoas reais, celulares antigos, conexões lentas e dados incompletos.
O sistema não estava morto.
Era pior.
Ele continuava funcionando sem compreender os próprios usuários.
Bem-vindo ao verdadeiro Web Design.
Aqui, criar uma página bonita é apenas o começo da sobrevivência.
1. O primeiro erro: acreditar que Web Design é decoração
Quando um iniciante escuta a expressão Web Design, normalmente pensa em:
cores;
fontes;
imagens;
botões;
menus;
animações;
organização visual.
Tudo isso faz parte do trabalho. Entretanto, representa apenas a camada mais visível.
Uma interface pode ser comparada à porta de entrada de um grande complexo tecnológico.
O usuário vê:
[ CONSULTAR SALDO ]
Mas atrás desse botão pode existir:
Usuário
↓
Navegador
↓
Front-end
↓
API REST
↓
Autenticação
↓
Servidor
↓
Regra de negócio
↓
CICS
↓
Programa COBOL
↓
Db2 ou VSAM
O botão é pequeno.
A operação que ele representa pode atravessar dezenas de componentes.
Esse é o primeiro grande ensinamento para o programador COBOL iniciante: a interface não existe sozinha.
Ela é uma camada de contato entre uma pessoa e um sistema.
Da mesma forma que uma tela BMS do CICS não é apenas um conjunto de campos posicionados no terminal, uma página Web não é apenas HTML com cores.
A tela precisa representar dados, regras, permissões, estados e possibilidades de ação.
Uma interface desconectada do sistema é como uma porta desenhada na parede.
Parece uma saída.
Mas não leva a lugar algum.
2. UI: a primeira barricada
UI significa User Interface, ou Interface do Usuário.
É tudo aquilo que a pessoa vê, toca, seleciona, preenche ou aciona.
Exemplos:
botões;
campos de formulário;
menus;
caixas de seleção;
tabelas;
ícones;
mensagens;
barras de progresso;
janelas;
links;
alertas.
A UI funciona como a primeira barricada entre o usuário e a complexidade do sistema.
Quando bem construída, ela organiza a interação.
Quando mal construída, ela libera o caos.
Considere este botão:
[ OK ]
O que significa “OK”?
Confirmar uma compra?
Excluir um cadastro?
Sair do sistema?
Enviar um pagamento?
Agora observe:
[ CONFIRMAR PAGAMENTO ]
A segunda opção reduz a incerteza.
Em sistemas corporativos, clareza é mais importante do que criatividade excessiva.
Um botão não precisa surpreender o usuário. Ele precisa comunicar.
Uma boa UI deve responder a três perguntas:
1. O que é este elemento?
2. O que posso fazer com ele?
3. O que acontecerá depois?
Essa lógica lembra um comando COBOL.
Quando vemos:
PERFORM CALCULAR-TOTAL
entendemos a intenção da operação.
Agora imagine:
PERFORM ROTINA-X
Pode funcionar, mas exige investigação.
Botões com nomes genéricos são o equivalente visual de parágrafos chamados ROTINA-X, PROCESSO-01 ou FAZ-COISA.
Funcionam tecnicamente.
Fracassam semanticamente.
3. UX: sobreviver não é apenas manter o sistema ligado
UX significa User Experience, ou Experiência do Usuário.
A UI pergunta:
Como esta tela se apresenta?
A UX pergunta:
O usuário consegue alcançar seu objetivo?
Essa diferença é fundamental.
Uma aplicação pode ser visualmente impecável e ainda oferecer uma experiência terrível.
Imagine um portal bancário com:
animações sofisticadas;
fotografia profissional;
tipografia moderna;
transições suaves;
gráficos elegantes.
Agora imagine que:
o usuário não encontra o saldo;
a transferência exige doze etapas;
a sessão termina sem aviso;
o botão Voltar apaga os dados;
o erro apresenta apenas
HTTP 500;o comprovante não pode ser baixado.
A UI pode ser bonita.
A UX está em estado terminal.
Uma experiência digital envolve toda a jornada:
Entrada no sistema
↓
Compreensão da tela
↓
Localização da função
↓
Execução da tarefa
↓
Retorno do sistema
↓
Confirmação do resultado
Se qualquer etapa falhar, a experiência será prejudicada.
Exemplo prático
O usuário preenche um cadastro e pressiona Salvar.
Uma interface ruim não mostra nada.
Ele clica novamente.
E novamente.
No banco de dados, três registros são criados.
Uma interface melhor apresenta:
Salvando cadastro...
Durante o processamento, o botão fica temporariamente desabilitado.
Depois:
Cadastro concluído com sucesso.
Ou:
Não foi possível concluir o cadastro.
Revise os campos destacados.
Isso é UX.
Não é apenas beleza.
É comunicação durante o processamento.
4. O usuário real não vive no ambiente de testes
Nos protótipos, tudo parece funcionar.
A conexão é rápida.
A tela é grande.
Os dados estão completos.
O usuário sabe exatamente onde clicar.
Então a aplicação entra em produção.
É nesse momento que os sobreviventes aparecem.
O usuário real pode estar:
usando um celular antigo;
com conexão instável;
sob forte luz solar;
utilizando apenas uma mão;
com pressa;
com baixa visão;
sem conhecimento técnico;
preenchendo o formulário pela primeira vez;
tentando recuperar uma senha esquecida;
interrompido por mensagens e chamadas.
Projetar para um usuário ideal é como montar uma base de sobrevivência assumindo que nunca faltará energia, água ou alimento.
O mundo real acabará testando cada suposição.
Por isso, o Web Designer precisa investigar:
Quem utilizará o sistema?
O que essa pessoa deseja fazer?
Em qual dispositivo?
Em qual contexto?
Com qual frequência?
Quais erros ela pode cometer?
Quais informações ela já conhece?
Quais limitações podem existir?
Esse processo é chamado de design orientado ao usuário.
Ele não significa simplesmente perguntar:
Qual cor você prefere?
O usuário pode gostar de azul e ainda precisar de uma solução completamente diferente daquela que imaginou.
O papel do profissional é compreender o problema.
5. A diferença entre pedido e necessidade
Um usuário pode dizer:
Quero um botão maior.
Mas o problema real pode ser:
baixo contraste;
área de clique pequena;
excesso de elementos na tela;
posição inadequada;
texto confuso;
dificuldade de navegação.
Da mesma forma, um usuário pode pedir:
Quero mais opções no menu.
Talvez ele não precise de mais opções.
Talvez precise encontrar melhor as opções existentes.
O bom designer não registra apenas a solicitação. Ele investiga a necessidade.
É como analisar um ABEND.
O código exibido é o sintoma.
A causa pode estar em outro ponto.
S0C7
↓
Dado inválido
↓
Campo não inicializado
↓
Arquivo com formato inesperado
↓
Regra de validação ausente
No design ocorre algo semelhante:
Usuário não encontra função
↓
Menu confuso
↓
Categorias inadequadas
↓
Arquitetura da informação mal planejada
O clique errado é o sintoma.
A organização pode ser a causa.
6. Acessibilidade: ninguém deve ser deixado do lado de fora
Em um cenário de sobrevivência, uma comunidade que abandona parte de seus membros torna-se mais fraca.
Na Web acontece o mesmo.
Acessibilidade significa criar produtos que possam ser utilizados pelo maior número possível de pessoas.
Isso envolve considerar usuários com:
limitações visuais;
limitações auditivas;
limitações motoras;
limitações cognitivas;
dificuldades temporárias;
restrições do ambiente.
Uma aplicação acessível deve considerar:
navegação por teclado;
leitores de tela;
foco visível;
contraste;
estrutura semântica;
textos alternativos;
mensagens compreensíveis;
áreas de toque adequadas;
formulários identificados corretamente.
Exemplo: informação apenas por cor
Verde = aprovado
Vermelho = reprovado
Nem todos conseguem distinguir essas cores.
Uma alternativa melhor:
✓ Aprovado
✕ Reprovado
Agora existem três sinais:
cor;
símbolo;
texto.
Exemplo: campo sem identificação
<input type="text" placeholder="Digite aqui">
Digite o quê?
Uma versão adequada:
<label for="email">E-mail</label>
<input id="email" type="email">
O label não é apenas uma conveniência.
Ele ajuda leitores de tela, amplia a clareza e melhora a interação.
Curiosidade Bellacosa
A acessibilidade beneficia pessoas que não possuem uma deficiência permanente.
Considere:
Permanente:
Pessoa com baixa visão.
Temporária:
Pessoa com o braço imobilizado.
Situacional:
Pessoa usando o celular sob forte luz solar.
Todos podem se beneficiar de bom contraste, botões maiores e navegação clara.
Acessibilidade não é caridade.
É engenharia de qualidade aplicada à experiência.
7. Responsividade: quando o espaço seguro diminui
Responsividade é a capacidade de a interface adaptar-se a diferentes telas e condições.
Um erro clássico é construir uma interface para desktop e depois reduzir tudo até caber no celular.
Isso não é responsividade.
É compressão visual.
Uma tela responsiva deve reorganizar:
conteúdo;
navegação;
prioridade;
espaçamento;
tamanho;
comportamento;
interação.
Considere uma tabela:
| Pedido | Cliente | Data | Valor | Status | Vendedor | Ações |
Em uma tela grande, ela pode funcionar.
No celular, pode transformar-se em:
PEDIDO #5821
Cliente: Carlos Mendes
Valor: R$ 320,00
Status: Em separação
[ VER DETALHES ]
Perceba que os dados não foram simplesmente encolhidos.
Eles foram reorganizados.
Mobile First
Uma abordagem útil é começar projetando para telas pequenas.
Isso força o time a responder:
O que é realmente essencial?
Qual é a ação principal?
Quais informações podem esperar?
O que deve permanecer sempre visível?
Depois, a interface pode crescer para telas maiores.
É como montar uma mochila de sobrevivência.
Quando o espaço é limitado, levamos o que realmente importa.
8. Arquitetura da informação: o mapa da zona segura
Arquitetura da informação é a organização dos conteúdos e funcionalidades.
Ela determina:
quais páginas existirão;
como serão agrupadas;
quais nomes serão utilizados;
como o usuário navegará;
onde encontrará cada função;
como retornará ao ponto anterior.
Imagine este menu:
Produtos
Soluções
Serviços
Recursos
Outros
Mais
Área
Opções
Tecnicamente, existem caminhos.
Na prática, ninguém sabe aonde levam.
Agora considere:
Cursos
Trilhas
Desafios
Certificados
Comunidade
Meu progresso
A segunda estrutura comunica melhor.
O menu não é a arquitetura
O menu é apenas uma representação da organização.
A arquitetura existe antes dele.
Pense em uma biblioteca.
As placas são a navegação.
As categorias, índices, estantes e relações entre livros formam a arquitetura da informação.
Uma aplicação grande pode possuir:
centenas de páginas;
diferentes perfis;
múltiplos fluxos;
funções restritas;
dados relacionados.
Sem arquitetura, o sistema transforma-se em uma cidade abandonada: ruas existem, edifícios permanecem de pé, mas ninguém sabe onde encontrar recursos.
9. Design conectado à arquitetura do sistema
Agora chegamos ao ponto em que muitos designers param.
Atrás da interface existem:
regras de negócio;
dados;
permissões;
integrações;
processamento;
serviços;
bancos de dados.
Uma tela de pedidos não pode ser projetada sem compreender os estados do pedido.
Exemplo:
Criado
↓
Pagamento aprovado
↓
Em separação
↓
Enviado
↓
Entregue
Também pode existir:
Criado
↓
Pagamento recusado
↓
Cancelado
O designer precisa saber:
quem pode cancelar;
em qual momento;
quais ações são irreversíveis;
quando é necessária uma confirmação;
quais informações precisam ser apresentadas;
como comunicar uma falha.
Exemplo de permissão
Um operador pode visualizar o pedido.
Um supervisor pode alterar o status.
Um administrador pode cancelar.
A interface precisa refletir essas permissões.
Não basta esconder um botão visualmente e acreditar que o problema está resolvido. A segurança deve existir também no servidor.
Interface oculta botão
+
Back-end valida permissão
=
Proteção adequada
Aqui surge um princípio importante:
A interface comunica a regra, mas o sistema deve garantir a regra.
10. Os estados que caminham escondidos
Ao projetar uma tela, iniciantes costumam desenhar apenas o estado perfeito.
Dados completos.
Sistema disponível.
Usuário autorizado.
Conexão rápida.
Mas uma interface real pode possuir vários estados:
Inicial
Carregando
Com resultados
Sem resultados
Com erro
Sem conexão
Sem permissão
Dados incompletos
Processamento pendente
Sessão expirada
Estado de carregamento
Consultando pedidos...
Estado vazio
Nenhum pedido foi encontrado.
Estado de erro
Não foi possível consultar os pedidos.
Tente novamente.
Estado de permissão
Seu perfil não possui acesso a esta função.
Estado de sessão expirada
Sua sessão terminou por segurança.
Entre novamente para continuar.
Projetar apenas a tela com dados é como preparar uma fortaleza apenas para dias ensolarados.
A primeira tempestade revelará tudo o que foi esquecido.
11. A API: o mensageiro entre os territórios
Uma API permite a comunicação entre partes de um sistema.
Exemplo:
Front-end
↓
GET /pedidos/5821
↓
API
↓
Regra de negócio
↓
Banco de dados
↓
Resposta JSON
↓
Interface atualizada
Uma resposta pode ser:
{
"pedido": 5821,
"cliente": "Carlos Mendes",
"valor": 320.00,
"status": "EM_SEPARACAO"
}
O designer não precisa implementar toda a API.
Entretanto, precisa compreender que:
os dados podem demorar;
a requisição pode falhar;
a resposta pode vir vazia;
o usuário pode não possuir permissão;
o serviço pode estar indisponível;
o formato pode mudar;
uma operação pode continuar em segundo plano.
Isso influencia a interface.
Se uma operação demora trinta segundos, não podemos deixar o usuário olhando para uma tela imóvel.
Podemos mostrar:
Processando solicitação...
Você pode continuar navegando.
Avisaremos quando o processo terminar.
Conhecer o funcionamento técnico permite projetar melhores respostas humanas.
12. Front-end: onde a barricada ganha forma
O Front-end é a camada executada no navegador.
As três tecnologias fundamentais são:
HTML → estrutura
CSS → apresentação
JavaScript → comportamento
HTML
O HTML organiza o conteúdo.
<h1>Consulta de pedidos</h1>
<label for="numero">Número do pedido</label>
<input id="numero" type="text">
<button type="submit">Consultar</button>
CSS
O CSS controla aparência e layout.
button {
padding: 12px 20px;
border-radius: 6px;
font-weight: bold;
}
JavaScript
O JavaScript controla comportamentos.
button.addEventListener("click", consultarPedido);
O Web Designer não precisa necessariamente tornar-se um desenvolvedor completo.
Mas compreender esses fundamentos ajuda a criar interfaces viáveis, consistentes e conscientes.
Estados de um botão
Um botão não possui apenas uma aparência.
Ele pode estar:
Normal
Com o mouse sobre ele
Com foco do teclado
Pressionado
Desabilitado
Carregando
Concluído
Com erro
Um Design System deve considerar essas variações.
13. Back-end: a sala de máquinas
O Back-end executa operações que normalmente não aparecem diretamente para o usuário.
Ele pode cuidar de:
autenticação;
autorização;
regras de negócio;
bancos de dados;
integrações;
processamento;
envio de mensagens;
auditoria.
Considere um formulário:
Nome
E-mail
Senha
[ CRIAR CONTA ]
Atrás dele:
Validar nome
Validar e-mail
Verificar duplicidade
Validar senha
Criptografar senha
Criar usuário
Registrar auditoria
Enviar confirmação
Retornar resultado
Cada etapa pode gerar uma mensagem diferente:
O e-mail informado é inválido.
Este e-mail já está cadastrado.
A senha deve possuir pelo menos oito caracteres.
Não foi possível enviar a confirmação.
Cadastro concluído.
Sem compreender o Back-end, o designer pode criar apenas um espaço genérico para erros.
Com algum conhecimento técnico, ele consegue projetar uma experiência mais precisa.
14. O paralelo com COBOL, CICS e mainframe
Para o programador COBOL iniciante, a arquitetura pode ser visualizada assim:
Usuário
↓
Página Web
↓
JavaScript
↓
API REST
↓
z/OS Connect
↓
CICS
↓
Programa COBOL
↓
Db2 ou VSAM
O usuário clica:
[ CONSULTAR CLIENTE ]
A aplicação pode executar:
1. Validar os dados no navegador.
2. Enviar a requisição para a API.
3. Autenticar o usuário.
4. Converter a chamada para o ambiente mainframe.
5. Acionar uma transação CICS.
6. Executar o programa COBOL.
7. Consultar Db2 ou VSAM.
8. Retornar os dados.
9. Atualizar a interface.
No COBOL, poderíamos imaginar:
IDENTIFICATION DIVISION.
PROGRAM-ID. CONSULTA-CLIENTE.
PROCEDURE DIVISION.
PERFORM VALIDAR-ENTRADA
IF DADOS-VALIDOS
PERFORM CONSULTAR-CLIENTE
PERFORM MONTAR-RESPOSTA
ELSE
PERFORM MONTAR-ERRO
END-IF
GOBACK.
A interface precisa estar preparada para ambas as respostas:
Cliente encontrado.
ou:
Cliente não localizado.
ou ainda:
Serviço temporariamente indisponível.
Esse é o encontro entre Web Design e mainframe.
A tela moderna pode ser a porta de entrada para um programa COBOL criado décadas atrás e continuamente modernizado.
15. Design System: o manual da comunidade
Em um grupo de sobreviventes, cada pessoa construir uma barricada de maneira diferente seria perigoso.
Uma usaria madeira.
Outra usaria metal.
Outra deixaria uma abertura porque achou visualmente interessante.
Em sistemas digitais, a falta de padrão também cria riscos.
Um Design System reúne:
componentes;
estilos;
regras;
padrões;
documentação;
princípios;
exemplos.
Exemplo:
Botão primário
Botão secundário
Campo de texto
Alerta
Modal
Tabela
Card
Menu
Breadcrumb
Também podem existir tokens:
Espaçamento pequeno: 8px
Espaçamento médio: 16px
Espaçamento grande: 24px
Borda pequena: 4px
Borda média: 8px
Fonte normal: 16px
Título: 32px
O Design System promove:
consistência;
velocidade;
acessibilidade;
reutilização;
melhor comunicação;
menor chance de erro.
Entretanto, ele não deve transformar-se em uma prisão.
Componentes existem para resolver problemas recorrentes, não para impedir toda evolução.
16. Tailwind CSS: o kit de ferramentas
Tailwind CSS utiliza classes utilitárias.
Exemplo:
<button class="px-4 py-2 rounded font-semibold">
Salvar
</button>
Nesse caso:
px-4 → espaçamento horizontal
py-2 → espaçamento vertical
rounded → bordas arredondadas
font-semibold → fonte com maior peso
Tailwind pode acelerar a implementação e aproximar design e código.
Porém, existe um alerta:
Uma ferramenta de CSS não cria automaticamente uma boa experiência.
É possível construir uma interface confusa usando Tailwind.
É possível construir uma interface excelente usando CSS tradicional.
A ferramenta implementa decisões.
Ela não substitui a investigação.
17. Passo a passo para projetar uma interface sobrevivente
Passo 1 — Descubra o problema
Pergunte:
O que o usuário precisa fazer?
Não comece pela cor.
Comece pela necessidade.
Passo 2 — Conheça o usuário
Investigue:
conhecimento;
contexto;
dispositivo;
frequência de uso;
dificuldades;
objetivos.
Passo 3 — Mapeie o fluxo
Exemplo:
Entrar
↓
Localizar pedido
↓
Visualizar detalhes
↓
Solicitar cancelamento
↓
Confirmar
↓
Receber resultado
Passo 4 — Organize a informação
Defina:
títulos;
categorias;
menus;
prioridades;
relacionamentos.
Passo 5 — Identifique regras do sistema
Pergunte:
Quem pode fazer?
Quando pode fazer?
Quais dados são necessários?
Quais erros podem acontecer?
Passo 6 — Projete todos os estados
Não desenhe apenas o cenário perfeito.
Inclua:
carregamento;
vazio;
erro;
sucesso;
falta de permissão;
ausência de conexão.
Passo 7 — Considere acessibilidade
Teste:
teclado;
contraste;
foco;
leitores de tela;
textos;
tamanho de toque.
Passo 8 — Considere diferentes telas
Verifique:
celular;
tablet;
notebook;
monitor grande;
ampliação de tela.
Passo 9 — Conecte design e tecnologia
Converse com:
desenvolvedores Front-end;
desenvolvedores Back-end;
analistas;
especialistas em banco de dados;
segurança;
infraestrutura;
usuários.
Passo 10 — Teste com pessoas reais
Observe sem explicar tudo.
Se o usuário não consegue avançar sem ajuda, existe uma pista.
18. Dicas Bellacosa para o Padawan do Web Design
Dica 1 — Não confie apenas no “está bonito”
Pergunte também:
Está claro?
Está acessível?
Está previsível?
Está funcionando?
Dica 2 — Mensagens de erro devem ajudar
Evite:
Erro 500.
Prefira:
Não foi possível concluir a operação.
Tente novamente em alguns instantes.
Dica 3 — Toda ação precisa de retorno
O usuário clicou?
Mostre que algo aconteceu.
Dica 4 — Não use apenas cor
Combine cor, texto e símbolo.
Dica 5 — Desenhe para dados ruins
Teste:
nomes muito longos;
campos vazios;
números grandes;
imagens ausentes;
respostas demoradas.
Dica 6 — O sistema não é o usuário
Uma mensagem tecnicamente precisa pode ser incompreensível para quem está usando a aplicação.
Dica 7 — Aprenda fundamentos
Frameworks mudam.
Os fundamentos permanecem:
estrutura;
hierarquia;
semântica;
acessibilidade;
comunicação;
feedback.
19. Curiosidades do abrigo digital
Curiosidade 1 — O estado vazio é uma oportunidade
Uma tela sem dados não precisa ser apenas vazia.
Ela pode orientar:
Você ainda não possui projetos.
Crie seu primeiro projeto para começar.
Curiosidade 2 — Velocidade percebida também importa
Mesmo quando uma operação demora, mensagens e indicadores reduzem a sensação de abandono.
Curiosidade 3 — O texto faz parte do design
Compare:
Enviar
com:
Enviar solicitação
O segundo pode ser mais claro dependendo do contexto.
Curiosidade 4 — Sistemas antigos podem ter interfaces modernas
COBOL não impede a existência de aplicações Web atuais.
APIs, z/OS Connect, CICS e serviços permitem conectar interfaces modernas a regras de negócio consolidadas.
Curiosidade 5 — A interface é uma tradução
Ela traduz:
Complexidade técnica
↓
Ações compreensíveis
20. Easter egg: o registro que ninguém deveria encontrar
Durante a investigação no CPD, o jovem programador abriu o log da aplicação.
Entre milhares de mensagens, encontrou:
02:17:33 USER CLICKED "OK"
02:17:33 ACTION UNKNOWN
02:17:34 REQUEST SENT
02:17:34 BUSINESS RULE REJECTED
02:17:34 ERROR MESSAGE HIDDEN
02:17:35 USER CLICKED AGAIN
02:17:35 USER EXPERIENCE INFECTED
Ele ficou em silêncio.
O problema nunca fora um vírus.
Também não era um processo morto.
Era um botão chamado OK.
O botão não explicava o que faria.
A mensagem de erro não aparecia.
O usuário clicava novamente.
O sistema criava uma nova tentativa.
Cada tentativa gerava outra.
E outra.
E outra.
A aplicação não estava sendo atacada por mortos-vivos.
Estava sendo atacada por decisões de design que se recusavam a morrer.
O programador abriu o código da interface e substituiu:
[ OK ]
por:
[ CONFIRMAR CANCELAMENTO ]
Depois adicionou:
O cancelamento não poderá ser desfeito.
Deseja continuar?
E finalmente:
Cancelamento concluído.
Naquele instante, o terminal parou de piscar.
O contador de erros começou a cair.
No monitor principal surgiu:
USER EXPERIENCE: RECOVERING
INTERFACE INTEGRITY: 97%
SYSTEM STATUS: HUMAN AGAIN
Conclusão: no fim, projetamos para pessoas
Web Design é muito maior do que criar uma página bonita.
Ele envolve:
UI;
UX;
pesquisa;
acessibilidade;
responsividade;
arquitetura da informação;
arquitetura do sistema;
Front-end;
Back-end;
APIs;
regras de negócio;
dados;
comunicação.
Uma interface é o ponto de encontro entre três mundos:
PESSOA
↘
INTERFACE
↗
SISTEMA
Se o projeto pensa apenas no sistema, pode tornar-se tecnicamente correto e humanamente impossível.
Se pensa apenas na aparência, pode tornar-se bonito e inutilizável.
Se pensa apenas no usuário, ignorando regras e limitações, pode propor algo inviável.
A boa experiência surge quando essas três dimensões trabalham juntas.
Para o programador COBOL iniciante, essa visão é especialmente valiosa.
Você poderá trabalhar em sistemas nos quais:
uma tela Web chama uma API;
a API acessa o z/OS;
o z/OS Connect chama o CICS;
o CICS executa um programa COBOL;
o COBOL consulta Db2 ou VSAM;
o resultado retorna para o navegador.
O usuário talvez nunca saiba que existe COBOL atrás daquela tela.
Mas sentirá imediatamente quando a interação for confusa, lenta ou incompleta.
Essa é a grande verdade escondida no subsolo do Web Design:
O usuário não enxerga a arquitetura inteira, mas experimenta todas as consequências dela.
Portanto, antes de perguntar apenas:
Está bonito?
Pergunte:
Está claro?
Está acessível?
Está organizado?
Está conectado ao sistema?
Está preparado para erros?
Está ajudando alguém?
Porque no mundo real das aplicações, interfaces mal projetadas raramente desaparecem.
Elas continuam caminhando.
Entram em produção.
Espalham confusão.
Geram chamados.
Produzem retrabalho.
E, quando ninguém investiga a causa, voltam na próxima versão com um novo layout, uma nova fonte e os mesmos velhos problemas.
No Bellacosa Mainframe, aprendemos a regra definitiva de sobrevivência:
Nunca julgue um sistema apenas pela tela inicial.
Atrás de cada botão existe uma operação.
Atrás de cada mensagem existe uma decisão.
Atrás de cada interface existe uma arquitetura.
E atrás de toda boa arquitetura deve existir uma pessoa que consiga utilizá-la sem precisar lutar contra ela.
- Aprenda mais sobre SEO
https://eljefemidnightlunch.blogspot.com/2013/10/a-busca-pelo-santo-seo-o-indice-oficial.html
