AcessibilidadeUX físico-digitalMotion

Theodoor para a Doorbotics

Um abridor portátil que deixa automática uma porta de giro comum. Desenhei o app para uma versão pré-MVP, pensada para pessoas que não conseguem abrir a porta com as próprias mãos.

CONTEXTO

As mãos que não abrem a porta também seguram o celular

O Theodoor deixa automática uma porta de giro já existente, sem furar, mexer na fiação ou modificar a casa. Seus usuários são pessoas para quem uma porta é um obstáculo diário: usuários de cadeira de rodas, pessoas se recuperando de um AVC e pessoas que convivem com artrite, esclerose múltipla, paralisia cerebral ou ELA.

Isso define a restrição que a interface precisa atender. Alcançar uma porta é um problema; agarrar e segurar é outro. A mesma força reduzida e as mesmas mãos instáveis que dificultam abrir uma porta dificultam operar a tela de um celular, e o app precisava funcionar exatamente para essas mãos.

O projeto foi curto e o objetivo era uma versão pré-MVP: um protótipo acabado o suficiente para ser testado e validado internamente, e claro o suficiente para um time de desenvolvimento trabalhar a partir dele. Eu não tinha o hardware, e várias decisões de produto ainda estavam sendo tomadas enquanto as telas eram desenhadas.

Meu papel·Product Designer·Contribuidor individual em um time de agência

ColaboraçãoFundadores da Doorbotics, QA e engenharia

Problema: Em uma revisão, o time discute o que um botão deveria dizer e o que a tela deveria mostrar enquanto a porta abre, sem porta nenhuma. Quatro pessoas raciocinando sobre um objeto físico que nenhuma de nós podia ver. Isso arrisca duas falhas ao mesmo tempo: fechar um comportamento que não sobreviveria ao hardware real, ou construir interface demais para compensar uma porta que ninguém via.

Proposta: Coloquei a porta dentro do protótipo: uma porta skeuomórfica que abria no mesmo tempo da real, para que ela estivesse presente em toda conversa. Designer, PM, QA e cliente podiam ver a mesma coisa acontecer e discutir sobre o que viam, e não sobre o que imaginavam.

Argumento: Isso deixou o time mais rápido e mais seguro, e trouxe algo que não tínhamos planejado: ver a porta simulada deixou óbvio que, para quem consegue ver a porta, a porta abrindo é a confirmação. A interface só precisa carregar o que o ambiente não mostra.

Problema: Num produto em que os usuários podem ter baixa visão, ou em que a atenção está na porta e não no celular, um feedback que só existe na tela não é feedback.

Proposta: Desenhei os estados do sistema para serem compreensíveis sem a tela, e a porta simulada tinha som além de movimento. Assim, o mesmo protótipo que deixava o time ver a porta também deixava parar de olhar para ela. Verificamos do jeito mais simples possível: numa revisão com o cliente, todo mundo desviou o olhar do celular e acompanhou o que o sistema fazia só pelo som.

Argumento: Foi uma checagem informal, não um estudo, mas respondeu à única pergunta que importava naquele momento: se a camada não visual se sustentava sozinha o bastante para valer a pena refinar.

Prototipagem de comportamento

Fazendo uma porta falhar, com segurança, antes de ela existir

A Doorbotics trouxe os cenários: o que deveria acontecer quando a porta encontra um obstáculo, quando não consegue completar o percurso, quando a conexão cai. Telas estáticas não resolviam nenhum deles. Então construí um simulador de protótipo que reproduzia o comportamento do sistema ao longo do tempo (tempo, transições e falhas, não só telas) e o transformei em um blueprint no Figma para o handoff.

Obstrução e proteção contra esmagamento
Cenário
A porta encontra um corpo ou um objeto no meio do movimento e o hardware para.
O que precisava resolver
Se a interface lê a parada como o sistema de segurança funcionando ou como uma falha.
Virou
Estados diferentes para uma parada de proteção e um erro de verdade, com caminhos de recuperação diferentes.
Percurso bloqueado e abertura parcial
Cenário
A porta começa a abrir e não consegue completar o movimento.
O que precisava resolver
O que o app mostra quando o resultado físico é parcial, e não sucesso ou falha.
Virou
Um estado intermediário com uma próxima ação visível, em vez de um spinner ambíguo.
Offline e fora de alcance
Cenário
O celular perde a conexão Bluetooth enquanto a pessoa está em frente à porta.
O que precisava resolver
O que o app pode afirmar com honestidade sobre uma porta que não alcança mais.
Virou
Estado da conexão separado do estado da porta, para o app parar de relatar o que não consegue ver.

Não havia hardware para testar nada disso. Simular o comportamento é o jeito de discutir um produto físico antes que ele possa ser tocado.

Resultado

Um pré-MVP pronto para o time construir

O protótipo foi entregue como planejado, e o time de desenvolvimento está construindo o pré-MVP a partir dele. Uma única direção de interface agora reúne o que eram várias ideias concorrentes do lado do cliente, dentro das restrições técnicas de um projeto curto.

Estados da porta, da conexão e de erro mapeados em um único modelo de comportamento
Feedback desenhado para funcionar sem a tela, não só nela
Edge cases reproduzidos em um simulador e traduzidos em um blueprint no Figma para o handoff
Motion refinado em Lottie, com fundações de UI reutilizáveis para configuração, erros e recuperação