overview_
Pergunte a um garçom o que ele pensa sobre o sistema de POS que usa e você não obterá uma resposta medida. Você obterá uma reclamação específica e vívida sobre uma tela, em um momento, em um turno — a aba que ele não conseguia encontrar às 23h com seis pessoas esperando, a conta que ele não conseguia dividir sem chamar um gerente, a tela tão brilhante que ele parou de conseguir lê-la duas horas depois do início de um turno de bar.
Ouvimos dezoito versões distintas dessa reclamação. Elas se resumiam a três coisas: os atendentes não conseguiam ver o que precisavam, não conseguiam acessá-lo rápido o suficiente e não conseguiam corrigi-lo quando algo dava errado.
O POS existente fazia o que todo POS no mercado faz. Gerenciava mesas, recebia pedidos, abria e fechava contas. Auditamos nove sistemas concorrentes, incluindo o nosso, e cada um deles lidava com esses conceitos básicos de forma competente. O que nenhum deles lidava era com a parte com a qual os garçons realmente lutavam — personalizar a interface de acordo com a forma como uma pessoa específica trabalha, mesclar e transferir contas sem atrito e navegar nela com velocidade sob pressão.
Essa lacuna era o produto.
Como poderíamos simplificar a interface de controle de consumo do bar para reduzir erros e melhorar a velocidade do serviço para garçons durante turnos movimentados?
O custo de errar não era abstrato. Um garçom que não consegue encontrar uma mesa é uma mesa esperando. Uma conta que não pode ser dividida é um gerente tirado do chão. Um cancelamento que leva seis toques é receita vazando, e é o tipo de vazamento que nunca aparece em um relatório porque ninguém registra os noventa segundos que perdeu.
Havia um segundo problema por baixo do primeiro, e acabou importando mais. Cada atendente usando nosso PDV já havia desenvolvido memória muscular em torno dele — memória muscular ruim, em uma interface ruim, mas real. Qualquer redesenho bom o suficiente para corrigir a interface era, por definição, suficientemente desconhecido para desacelerá-los no primeiro dia. Corrigir o sistema e não perturbar seus usuários eram objetivos diretamente opostos.
Essa tensão é sobre o que o projeto era na verdade.
papel_
Trabalhei na fase de pesquisa ao lado da líder de design, e fui a mão mais ativa na execução do design e em levar o trabalho para a sala com desenvolvedores, proprietários de produto e stakeholders internos.
Essa segunda parte é a parte que vale a pena prestar atenção. Uma descoberta de pesquisa não sobrevive ao contato com um backlog de desenvolvimento por si só. Alguém tem que estar na revisão, explicar por que o caminho de tela escura não é um diferencial, argumentar pelo passo de autenticação de dois servidores quando é mais fácil lançar sem isso, e manter a posição quando uma decisão de design é tratada como uma preferência. Esse era meu trabalho neste projeto, e é por isso que as decisões nesta página estão no produto em vez de em um apresentação.
NO QUE TRABALHEI
· Visualizador de Abas da Barra
· Sistema de teclado e teclado numérico
· Tela de pedidos
· Caminho do modo escuro
· Uma parte das ações de abas
· Apresentação interna para dev, produto e stakeholders
O QUE O TIME POSSUÍA
· Programa de pesquisa em quatro áreas
· Auditoria competitiva de nove sistemas POS
· Priorização e estrutura de backlog
pesquisa_
A pesquisa funcionou em quatro fluxos em vez de um, o que é incomum para um projeto de nível de recurso e é a razão pela qual as conclusões se mantiveram.
ENTREVISTAS
Quinze atendentes e gerentes em diferentes tipos de estabelecimento, trabalhando a partir de um guia que abrange fluxo de trabalho, tratamento de erros, usabilidade da interface, velocidade do atendimento, curva de aprendizado e confiabilidade. Mapeamos os resultados em dezoito temas de dor recorrentes.
PESQUISA SECUNDÁRIA
Diretrizes do Material Design, Nielsen Norman Group e documentação de concorrentes. Três descobertas que se mantiveram ao longo de todo o projeto: a legibilidade é mais importante do que parece quando alguém está olhando para uma tela por oito horas, a capacidade de encontrar ações determina diretamente a velocidade de pedidos, e os atendentes precisam que a tela se adapte ao modo como eles trabalham pessoalmente.
AUDITORIA DE OUTROS SISTEMAS
Nove sistemas POS, cinco com análises completas — incluindo uma análise honesta do nosso próprio produto, que apontou a interface desatualizada, os padrões de ação confusos e a dependência de soluções alternativas manuais. Auditar o produto do seu empregador na frente do seu empregador é desconfortável e foi o slide mais útil da apresentação.
EXPERTISE INTERNA
Várias pessoas na equipe haviam trabalhado como garçons e possuíam certificação de serviço atual. Usávamos-as como uma verificação permanente para saber se um design sobreviveria a um turno real.
15
atendentes e gerentes entrevistados
18
temas de dor recorrente mapeados
9
Sistemas POS auditados, 5 com desmontagem completa
AUDITORIA DE VIESES
Realizamos uma auditoria de viés antes da análise — identificando viés de status quo, viés de confirmação, viés de especialista e viés de familiaridade, e verificando nossas conclusões contra cada um. O viés de especialista era o risco imediato: tínhamos ex-servidores na sala e teria sido fácil deixar a voz mais experiente e alta falar pelos quinze entrevistados.
decisão_
FAMILIARIDADE HERDADA VS. REDESENHO DE FOLHA LIMPA
O movimento óbvio era um redesenho do zero. A interface existente era desatualizada, os padrões de ação eram confusos, e tínhamos uma lista documentada de tudo que estava errado com ela. Reconstruir do zero era a opção mais provável de produzir algo do qual estávamos orgulhosos.
Nós não fizemos isso, e a razão veio da pesquisa em vez do gosto.
Três descobertas apontavam na mesma direção. Atendentes nomearam a curva de aprendizado como uma das principais frustrações. Gerentes nos disseram que o tempo de treinamento era um custo operacional real, não uma inconveniência. E nossos especialistas internos foram diretos ao dizer que um servidor no meio do turno não aprende — eles vão para onde o botão estava na semana passada e ficam irritados quando ele se move.
Então dividimos a superfície em duas. Onde um modelo mental anterior existia — layout, iconografia, convenções de nomenclatura, o fluxo de ordenação — mantivemos, mesmo onde poderíamos ter melhorado, porque o custo do reaprendizado superava o ganho. Onde nenhum modelo anterior existia, acima de tudo o Visualizador, fomos livres para projetar adequadamente, porque não havia nada para desaprender.
OPÇÃO A — REDESIGN COMPLETO · REJEITADO
Melhor interface no papel, pior primeira semana para cada servidor usando-a. Em uma categoria onde uma má primeira semana cancela o lançamento, não é uma troca que poderíamos fazer.
OPÇÃO B — APENAS REFORMULAÇÃO · REJEITADO
Deixa os problemas de descoberta e velocidade intocados. Isto é o que a maioria dos nossos concorrentes já tinha feito, e é por isso que a lacuna do mercado existia em primeiro lugar.
OPÇÃO C — DIVIDIR A SUPERFÍCIE · ESCOLHIDA
wireframes_
iteração_
A RODADA QUE NÃO FUNCIONOU
Nosso primeiro protótipo de média fidelidade foi rejeitado :(
Implementamos o Visualizador, visibilidade de abas com escopo de login, o perfil do usuário com cor e iniciais, e um alternador de grade/lista. O feedback retornou com nove mudanças obrigatórias: preservar familiaridade, refazer a visualização dividida, suavizar a transferência e mesclagem de abas, simplificar o agendamento, solicitar contagem de pessoal, reconfigurar o layout do painel, adicionar busca e filtragem reais, adicionar pistas visuais mais claras e resolver a propriedade de abas futuras.
Lidas juntas, as notas diziam uma coisa. Tínhamos projetado bem a nova funcionalidade e ainda não a tínhamos reconciliado com o sistema que as pessoas já conheciam. A restrição de familiaridade estava em nossa pesquisa desde o início; ainda não a tínhamos deixado nos constranger.
Então voltamos pela ideação uma segunda vez e saímos com um backlog priorizado em cinco áreas — unificando as superfícies do POS e da aba do bar, o Visualizador, o painel esquerdo, as ações da aba e o plano de piso. A segunda rodada é a que foi lançada.
RODADA 01
idealizar → esboçar → protótipo de média fidelidade
✕ REJEITADO
9 ALTERAÇÕES SOLICITADAS
RODADA 02
idealizar → esboçar → priorizar → média-fidelidade
✓ APROVADO!
interface_
Cinco decisões, cada uma rastreável a uma descoberta documentada. Estas são as que eu mantive durante o desenvolvimento.
01 · CAMINHO DA TELA DARK
Veio diretamente de atendentes descrevendo fadiga ocular e telas ilegíveis em ambientes de bares com pouca luz. Lê-se como uma escolha de estilo. Foi uma escolha orientada por descobertas.
02 · AUTENTICAÇÃO EM DOIS ATENDENTES NA MESCLAGEM
Veio de histórias de usuários sobre responsabilidade — mesclar as abas de dois atendentes move dinheiro e responsabilidade, e fazer isso silenciosamente cria disputas que ninguém consegue resolver depois. Adiciona uma etapa. Valia a pena adicionar a etapa, e esse foi o argumento que tive que apresentar no desenvolvimento.
03 · PERFIS POR ATENDENTE
Cor, iniciais e orientação de tela, incluindo um layout para canhotos. Respondeu à lacuna de personalização que nenhum concorrente havia preenchido. A opção para canhotos surgiu de observar como as pessoas realmente usam o dispositivo.
04 · VISUALIZADOR
Pesquisar, ordenar, filtrar e uma legenda de status, em uma superfície sem nenhum modelo mental anterior a preservar. Respondeu "busca de abas difícil" e "sem atualizações em tempo real", dois dos temas de dor mais frequentemente levantados.
05 · SISTEMA DE TECLADO E TECLADO NUMÉRICO
Entrada de nome do cliente com alternativa de passagem de cartão, entrada de código PIN com substituição de gerente, entrada de balança de peso. A maioria do atraso dos servidores descritos não era a tarefa, era a entrada.
resultado_
Uma parte das ações da aba foi entregue junto com essas quatro superfícies. As ações restantes e os floorplans do serviço de tabela foram projetados e estão aguardando desenvolvimento.
Não tenho métricas pós-lançamento para este trabalho, e prefiro admitir isto do que estimar. A fase de teste de usabilidade foi definida no plano do projeto e não foi executada antes da entrega.
O que eu tenho é isto: depois que o trabalho de abas de bar foi lançado, um cliente que usa nosso POS nos pediu para construir serviço de mesa e plantas de piso em cima disso. Esse pedido é o motivo pelo qual o produto expandiu para além de seu escopo original, e é a evidência mais direta que posso oferecer de que o trabalho entregue fez seu trabalho.
4 superfícies enviadas
visualizador · teclado e teclado numérico · tela de pedidos · caminho do modo escuro
Escopo expandido por solicitação do cliente
um cliente usando o POS pediu para que o serviço de mesa e plantas baixas fossem construídos em cima do trabalho de aba de bar
2 ciclos de design completos
a primeira rodada de protótipo foi rejeitada e reconstruída
reflexão_
Eu teria executado o teste de usabilidade. Definimos uma fase de teste e tratamos a revisão das partes interessadas como um substituto para ele. As partes interessadas informam se um design é aceitável para o negócio. Elas não podem informar se um atendente consegue encontrar uma aba em quatro segundos às 23h, e essa era a pergunta real.
Eu teria aplicado a restrição de familiaridade antes do primeiro protótipo, não depois. O achado estava em nossa pesquisa da fase de descoberta. Projetamos uma rodada sem ela, tivemos isso devolvido, e gastamos um ciclo completo aprendendo algo que já nos tinha sido dito. Pesquisa que não restringe o primeiro protótipo é pesquisa que você vai repetir.
PRÓXIMO PROJETO