SeniGo

SeniGo — acompanhantes verificados para o dia a dia, com o respaldo de instituições certificadas.

O SeniGo é uma plataforma de dois lados onde pessoas idosas, e as famílias que as apoiam, marcam acompanhantes verificados para as tarefas comuns que tornam possível continuar a viver em casa: compras, consultas médicas, passeios, companhia, recados, ajuda em casa, transportes.

Começou como um marketplace aberto, onde qualquer pessoa se podia inscrever para ajudar. Esse modelo foi abandonado — no papel, antes de existir uma linha de código — a favor de algo mais defensável: uma rede de cuidados com pagamento em custódia, onde cada acompanhante é verificado, formado e responsável perante uma instituição certificada. Essa mudança é a espinha deste case study, e é a decisão sobre a qual mais gostaria de ser questionado.

Função

Fundador e product designer — enquadramento do problema, estratégia de produto, IA, fluxos de UX, sistema de UI e a implementação funcional.

Cronologia

Conceito desde agosto de 2025. Mudança de modelo e candidaturas a programas de inovação e empreendedorismo até à primavera de 2026. Desenhado e construído entre maio e julho de 2026.

Distinções

Selecionado duas vezes para o StartUp Voucher (IAPMEI). Não avancei em nenhuma delas — estar a estudar a tempo inteiro tornava-o impossível.

Tipo

Projeto de fundador.

Design

Design system assente em primitivas Radix, tokens próprios, camada de movimento e acessibilidade.

Build

Next.js 15, TypeScript, Tailwind, PostgreSQL/Prisma, Clerk, Stripe Connect, Resend, Leaflet.

Idioma

Português (pt-PT), desenhado para o mercado português.

Porque vale a pena ler: isto não é um conjunto de ecrãs. É um produto com uma transação a funcionar, um processo de verificação, um modelo de custódia, um processo de disputa e quatro perfis de utilizador distintos — o que obrigou cada decisão de design a sobreviver ao contacto com uma restrição real.

A maioria das pessoas idosas quer continuar a viver em sua casa. O que se interpõe raramente é uma necessidade médica — é um conjunto de tarefas pequenas e banais: chegar a uma consulta do outro lado da cidade, subir dois andares com as compras, ter com quem falar numa terça-feira à tarde.

Essas tarefas caem num vazio. De um lado, a ajuda informal: um vizinho, um familiar, um nome que passa entre conhecidos. Do outro, as empresas de cuidados ao domicílio: contratos, mínimos de horas, compromissos mensais, avaliações. Nenhum dos dois serve para "preciso de alguém que vá comigo ao hospital na quinta-feira."

O problema central não é falta de pessoas dispostas a ajudar. É não existir uma forma fiável e sem compromisso de os dois lados se encontrarem.

Porque vale a pena resolver

A direção demográfica é conhecida, e optei deliberadamente por não construir o argumento sobre números que não verifiquei. O que usei foi estrutural: a faixa da "ajuda ocasional e ligeira" está genuinamente mal servida tanto pela opção informal como pela formal, e esse vazio não se fecha sozinho. É um problema durável, não uma moda.

Do lado da pessoa idosa

• Encontrar ajuda depende de sorte. Implica conhecer a pessoa certa. Isso não escala, não viaja entre cidades e não traz garantia nenhuma.
• A alternativa formal é grande demais. Os contratos de empresas foram feitos para cuidado contínuo. Quem precisa de quatro horas por mês é tratado e orçamentado como se precisasse de quarenta.
• A confiança é o verdadeiro bloqueio, não a oferta. Deixar entrar um estranho em casa — ou em casa da nossa mãe — é uma decisão de risco muito superior a pedir um transporte ou uma refeição. A fasquia do "como sei que esta pessoa é de confiança?" é diferente em natureza, não em grau.
• A fricção digital agrava tudo. Texto pequeno, formulários densos, passos seguintes pouco claros e fluxos de pagamento escritos para quem usa o banco no telemóvel todos os dias. Uma pessoa pode ser perfeitamente capaz e ainda assim ser derrotada por uma interface que assume fluidez.
• Quem procura muitas vezes não é quem é ajudado. Normalmente é um filho ou filha adulta. Isso divide o público do produto de uma forma que a maioria dos marketplaces nunca tem de gerir.

Do lado do acompanhante

• O trabalho existe mas é invisível. Passa-palavra, dinheiro em mão, sem registo. Nada se acumula.
• Nenhuma credencial viaja. Quem tem dez anos de experiência chega a cada família nova como um completo desconhecido e tem de ganhar confiança do zero de cada vez.
• Receber é um problema de relação. Cobrar a alguém com quem se acabou de passar a tarde — por vezes uma pessoa vulnerável — é desconfortável de uma forma que o freelancing comum não é.
• Não há proteção quando algo corre mal. Um serviço contestado, uma falta, uma acusação. Trabalho informal significa consequências informais, e quem tem menos poder é quem as absorve.
• O rendimento é imprevisível e impossível de comprovar — o que pesa em tudo, de um contrato de arrendamento a um crédito.

Como enquadrei o problema

Como podemos tornar a ajuda ocasional do dia a dia tão simples de marcar como uma reserva — sem perder a confiança que leva alguém a abrir a porta?

Todas as decisões das secções seguintes remetem para a segunda metade dessa frase.

O produto acabou com quatro perfis distintos, cada um com área, navegação e regras próprias. Isso não foi conveniência estrutural — veio da constatação de que estes grupos quase não partilham tarefas.

1 · A pessoa idosa

Precisa de ajuda numa tarefa concreta, num dia concreto, e de a conseguir marcar sem se sentir um peso.
Objetivos manter a independência; controlar quem entra em casa; não ter de envolver a família em cada pequena coisa.
Dificuldades a confiança digital varia enormemente; alvos pequenos e formulários densos; processos de vários passos em que não é claro ao que já se comprometeu. Uma confirmação e um pagamento confundem-se com facilidade.
Preocupações Quem é esta pessoa? É de confiança? Quanto vai custar? Posso cancelar? O que acontece se correr mal?

Consequência para o design: cada passo tem de ser legível e, ou reversível, ou claramente explicado antes de ser dado.

2 · O familiar — o utilizador invisível

Frequentemente é quem procura, avalia, compara e paga, enquanto a pessoa idosa é quem recebe o serviço. Está ansioso, sem tempo, e a agir em nome de outra pessoa.

Esta é a lacuna mais evidente do produto atual. Não existe forma de um filho adulto ter conta própria, gerir as reservas de um pai ou ser notificado quando um serviço é confirmado. Só identifiquei isto devidamente tarde, e é a primeira coisa que construiria a seguir. Nomeá-lo honestamente vale mais do que disfarçá-lo.

3 · O acompanhante

Precisa de um fluxo constante de pedidos, de uma forma de ganhar confiança depressa e de pagamento fiável.
Objetivos transformar trabalho informal e pago em mão em algo que se parece e se comporta como uma profissão.
Dificuldades provar que é de confiança sem histórico; o arranque a frio de zero avaliações; carga administrativa que não pediu.
Preocupações receber a tempo, estar protegido numa disputa, e não ter de lutar por nenhuma das duas coisas.

4 · A instituição

Lares, centros de dia, empresas de cuidados e clínicas.

Precisa de visibilidade, de um canal para colocar a sua equipa e de supervisão sobre o que é feito em seu nome.
Objetivos estender o serviço para além das suas paredes e aproveitar capacidade existente.
Preocupações reputação acima de tudo — o nome delas fica associado a quem avalizam, o que as torna um parceiro exigente mas extremamente valioso.

5 · O operador da plataforma

Não é um acessório. Verificação, resolução de disputas e prestação de contas são trabalho operacional diário, por isso a área de administração é um produto desenhado por direito próprio — incluindo a exportação completa de histórico para pedidos de autoridades, porque uma plataforma que coloca estranhos dentro de casas acabará por receber um.

Os cinco perfis são raciocinados a partir do domínio do problema e dos requisitos do próprio produto. Não resultam de entrevistas — ver a secção seguinte.

Nove meses antes da primeira linha de código

A ideia é de agosto de 2025. O desenvolvimento só começou em maio de 2026.

Os meses pelo meio foram para o conceito: definir o problema, pôr o modelo à prova e mudá-lo uma vez — substancialmente, e no papel. Essa sequência foi deliberada, e é a parte do processo que mais gostaria de ver avaliada. O que este produto tinha de mais arriscado nunca foi conseguir ser construído.

O que fiz de facto

Enquadramento do domínio. Mapeei as formas como esta ajuda é hoje arranjada — redes informais, empresas de cuidados ao domicílio, anúncios e grupos de Facebook — e olhei para aquilo a que cada uma renuncia. A ajuda informal é de confiança mas sem prestação de contas e impossível de encontrar. As empresas têm prestação de contas mas são grandes demais e lentas. Os anúncios encontram-se mas não trazem confiança nenhuma. Nenhuma opção reúne as três coisas.

Análise de produtos adjacentes. Olhei para a forma como marketplaces de tarefas e plataformas on-demand resolvem o matching, e concluí que a maioria dos seus padrões é exatamente o que não se deve copiar aqui. Otimizam para rapidez, comparação de preço e baixo compromisso. O cuidado precisa quase do oposto: verificação, responsabilização e um caminho mais lento e deliberado até ao compromisso. Importar um checkout de entrega de comida para aqui seria ativamente prejudicial.

Mapeamento de pressupostos. Em vez de fingir ter conclusões validadas, escrevi o que teria de ser verdade para o produto funcionar e ordenei os pressupostos por risco. O mais arriscado não era "as pessoas vão querer isto" — era:

A confiança, e não a oferta ou a procura, é a restrição determinante. Se conseguirmos fabricar confiança de forma credível, o marketplace funciona. Se não conseguirmos, o resto é irrelevante.

Todo o resto do produto foi depois desenhado como resposta a esse pressuposto. É por isso que verificação, custódia, relatórios de sessão e resolução de disputas existem antes de uma descoberta mais bonita ou de uma app móvel.

Pôr o projeto à frente de quem não lhe devia nada

Ao longo desse período levei o SeniGo a programas externos em vez de o manter no papel.

Candidatei-me duas vezes ao StartUp Voucher do IAPMEI, e fui selecionado nas duas. Não avancei em nenhuma — estava a estudar a tempo inteiro, o que tornava impossível a dedicação que o programa exige. Candidatei-me também a um programa de aceleração do Startup Leiria e não fui aceite.

Nada disto é research com utilizadores e não o vou vender como tal: um júri não é um cliente, e ser selecionado não prova que alguém quer o produto. O que fez foi obrigar a defender o argumento repetidamente, num tempo limitado, perante estranhos com cabeça comercial e nenhum interesse em serem convencidos.

Foi aí que o modelo original se desfez. Defender qualquer pessoa se pode inscrever para ajudar perante quem procura primeiro a responsabilidade civil tornou óbvio que a resposta que eu tinha não era suficiente.

A mudança: de "qualquer pessoa pode ajudar" para "só através de uma instituição"

O modelo original era aberto. Qualquer pessoa se podia registar como acompanhante, passar uma verificação e começar a aceitar trabalho — um marketplace convencional entre particulares.

Abandonei-o antes de começar o desenvolvimento. A razão foi o risco.

Num modelo aberto, a única defesa da plataforma é uma verificação feita uma vez, no registo. Se essa verificação estiver errada, ou se alguém mudar depois de a passar, não há mais nada entre um estranho e uma pessoa vulnerável sozinha em casa. Um registo criminal no dia um nada diz sobre o dia duzentos. A plataforma acaba a carregar responsabilidade total por um perigo que não tem qualquer forma continuada de ver.

A mudança: o acompanhante chega à plataforma através de uma instituição certificada — um lar, centro de dia, empresa de cuidados ou clínica — que o avaliza, o gere e tem o próprio nome associado à sua conduta.

O que isso compra não é uma verificação mais forte. É responsabilização continuada, por parte de uma organização que é fiscalizável, contactável e tem consideravelmente mais a perder do que um indivíduo. Move o produto de verificámos esta pessoa uma vez para há uma instituição por trás desta pessoa.

Mudou também tudo a jusante ao mesmo tempo: a página inicial passou a abrir com "cuidados de confiança através de instituições certificadas" em vez de uma lista de perfis; a aquisição de oferta passou a ser um problema B2B e não de consumo; e a arquitetura de informação ganhou um quarto perfil.

É a decisão que defenderia com mais convicção, e a que demorou mais tempo a chegar.

O que não fiz — dito com clareza

Não realizei entrevistas com utilizadores. Não realizei testes de usabilidade com pessoas idosas. Não fiz questionários, diary studies nem qualquer sessão moderada, e não tenho dados quantitativos porque o produto não foi colocado à frente de utilizadores reais.

Isso significa que tudo o que este case study afirma sobre usabilidade para pessoas idosas é juízo informado, não evidência. É raciocinado a partir do domínio e da prática de acessibilidade, e é exatamente o tipo de raciocínio que os testes de usabilidade existem para furar.

Esta etapa poderia ser aprofundada através de:

• 5 a 8 sessões moderadas com pessoas com mais de 70 anos, idealmente nos seus próprios dispositivos e em suas casas, observando o fluxo de descoberta → reserva sem ajuda
• Sessões paralelas com filhos adultos, para perceber onde os dois públicos divergem de facto
• Entrevistas com cuidadores informais sobre como encontram trabalho e como são pagos hoje
• Conversas com duas ou três instituições de cuidados, já que todo o modelo institucional assenta num pressuposto por testar sobre a vontade delas de participar

Esperaria que esse research invalidasse várias coisas em que acredito neste momento. É esse o objetivo de o fazer.

O percurso da pessoa idosa, da necessidade à ajuda

1 · Gatilho. "Tenho consulta na quinta e não tenho como lá chegar." A necessidade é específica, tem data e é normalmente um pouco urgente.

2 · Descobrir. Uma página de pesquisa pública — sem necessidade de conta. Filtros por cidade, tipo de serviço, preço e avaliação, com vista de mapa. Um atalho de geolocalização preenche o campo da cidade automaticamente, para que a primeira interação não exija escrever uma localização. Cada cartão de resultado carrega as três coisas que respondem a posso confiar nesta pessoa: símbolo de verificado, avaliação e nome da instituição.

3 · Avaliar. O perfil reúne biografia, serviços, idiomas, anos de experiência, disponibilidade e avaliações — incluindo as respostas do acompanhante às avaliações, que dizem mais sobre responsabilização do que a média de estrelas.

4 · Pedir. Um formulário de reserva abre sobre o perfil: tipo de serviço, título em linguagem simples, data e hora, duração, cidade, morada, notas. O preço total atualiza em tempo real à medida que a duração muda. Sem pagamento neste passo.

5 · Aguardar aceitação. O acompanhante aceita ou recusa. Só depois da aceitação aparece o pagamento.

6 · Pagar → serviço → confirmar → avaliar. O pagamento fica retido pela plataforma, não passa diretamente.

Porquê esta ordem

Pedir dinheiro antes de a outra pessoa ter dito que sim imitaria um checkout, não um pedido de ajuda. As pessoas não comprometem dinheiro antes de saberem que alguém vem. Separar pedido e pagamento elimina também toda uma classe de reembolsos, e dá ao acompanhante uma decisão real em vez de uma obrigação.

O percurso do acompanhante

Registo → escolher perfil → dados e documentos → em análise → aprovação humana → formação obrigatória e quiz → onboarding Stripe → opcionalmente juntar-se a uma instituição → receber pedidos → aceitar → prestar o serviço → marcar como terminado → submeter relatório → receber.

Há três barreiras entre registar-se e ganhar dinheiro. Todas são deliberadas, e todas estão explicadas em Decisões-chave de UX.

O aperto de mão final

Esta é a parte do fluxo com que estou mais satisfeito. Fechar uma reserva exige as duas pessoas:

• O acompanhante marca o serviço como terminado.
• A pessoa idosa confirma que aconteceu.
• Só então o dinheiro é libertado.

Nenhum dos lados fecha o ciclo sozinho. Três válvulas de segurança impedem que essa simetria se torne uma armadilha:

1. Se a pessoa idosa nunca confirmar, uma libertação automática conclui a reserva ao fim de 48 horas — para que um acompanhante nunca fique refém de inacção, esquecimento ou de alguém que simplesmente não usa muito a aplicação.
2. Se a pessoa idosa contestar, a reserva passa a estado de disputa e um humano resolve, com reembolsos reais quando a razão está do seu lado.
3. O pagamento fica bloqueado até o acompanhante submeter o relatório de sessão — um relato curto do que aconteceu, pontos positivos e eventuais incidentes.

Este terceiro ponto é a peça de design que apontaria primeiro. Liga uma obrigação de qualidade ao momento que mais importa ao acompanhante, pelo que o registo é escrito enquanto está fresco, e as famílias ganham um histórico escrito de cuidado que de outra forma nunca teriam.

O produto divide-se em duas camadas que fazem trabalhos genuinamente diferentes.

A camada pública

Início, como funciona, acompanhantes, instituições, preços, segurança, FAQ, blog, sobre, contacto, legal.

A sua função é persuasão e construção de confiança antes de alguém criar conta. Duas decisões importam aqui:

• A pesquisa fica na camada pública, não atrás de login. Uma família deve poder ver acompanhantes reais e verificados na sua cidade antes de se comprometer com o que quer que seja. Esconder a prova atrás de um registo seria pedir confiança sem oferecer nenhuma. É uma decisão de aquisição tanto quanto de IA — é também o que torna os perfis individuais indexáveis.
• A segurança tem página própria de topo em vez de viver dentro das FAQ. Se a confiança é a restrição determinante de todo o negócio, a história da confiança merece um destino, não um acordeão fechado.

A camada privada

Adapta-se ao perfil: a barra lateral apresenta um produto diferente consoante quem está autenticado.

• Sénior: Início · Encontrar · Reservas · Mensagens · Favoritos · Notificações · Perfil · Definições
• Acompanhante: Início · Reservas · Mensagens · Avaliações · Ganhos · Formação · Notificações · Perfil · Definições
• Instituição e Administração têm áreas completamente separadas.

O raciocínio

Um modelo de conta, quatro produtos. Um sénior e um acompanhante quase não partilham tarefas. Mostrar a um sénior um separador "Ganhos" seria ruído, e sugeriria discretamente que a ferramenta não foi feita para ele. Navegação adaptada ao perfil não é um atalho técnico — é o que evita que cada pessoa tenha de filtrar a metade do produto que não lhe pertence.

As reservas são a espinha dorsal. Tudo na camada privada assenta numa reserva em vez de existir como sistema paralelo: mensagens, relatório de sessão, pagamento, recibo, avaliação, disputa. Um objeto, uma cronologia, um sítio onde procurar.

As mensagens estão ligadas a uma reserva, não a uma caixa de entrada livre. Três razões, por ordem de peso: dá contexto a cada conversa, para que ninguém se pergunte quem é este e porque me escreve; mantém a relação na plataforma, onde vivem as proteções; e elimina a carga de moderação de um sistema de mensagens aberto. O custo é que duas pessoas que trabalharam bem juntas não conseguem falar facilmente fora de uma reserva — um compromisso aceite, revisitado em O que melhoraria.

O estado de verificação é mostrado de forma assimétrica. Só acompanhantes totalmente aprovados aparecem na pesquisa pública, por isso um sénior nunca tem de avaliar se alguém está verificado — a resposta é sempre sim. Em paralelo, o acompanhante vê o seu próprio estado de verificação em destaque no seu painel, porque para ele é a coisa mais importante do ecrã. Os mesmos dados, dois públicos, dois tratamentos.

A exploração que importou foi estrutural, não visual. Estas são as alternativas que pesei e o que decidiu cada uma.

Entrada na reserva: página ou sobreposição

Uma página dedicada é mais fácil de construir e dá mais espaço. Escolhi uma sobreposição lançada a partir do perfil do acompanhante, porque uma página inteira leva o utilizador para longe da pessoa que está a contratar exatamente no momento em que surge a dúvida. Manter o rosto, o nome, o símbolo de verificado e a avaliação visíveis por trás do formulário mantém a decisão ancorada a uma pessoa e não a uma transação.

Quanto deve o pedido perguntar

O pedido mínimo viável é tipo de serviço, título, data e hora, duração e cidade. Morada e notas são opcionais nesta fase.

Foi uma decisão de privacidade tanto quanto de fricção: um sénior não deve ter de revelar a morada de casa para enviar um pedido que pode ser recusado. A morada torna-se relevante depois de alguém aceitar.

Onde o custo é revelado

As opções eram preço no fim, um passo de revisão separado, ou cálculo em tempo real. Escolhi tempo real: o total recalcula dentro do formulário à medida que a duração muda, com a decomposição imediatamente acima do botão de submeter. Sem surpresa no fim, e sem um passo extra cujo único propósito seria dizer o que o passo anterior já sabia.

Duração como escolha, não como campo numérico

Uma a doze horas como opções discretas em vez de um campo numérico livre. Elimina valores inválidos, elimina ambiguidade de decimais, elimina trabalho de teclado no telemóvel, e transforma uma pergunta que exige compor uma resposta noutra que exige apenas reconhecê-la. Para este público, reconhecer ganha sempre a recordar.

Onboarding: um formulário longo ou passos

O registo do acompanhante é genuinamente pesado — documento de identificação frente e verso, registo criminal, selfie com o documento, NIF, data de nascimento. Um único formulário corrido leria como um muro e perderia pessoas logo no início.

Dividi-o em dois passos com indicador de progresso explícito (Passo 1 de 2, 50% → 100%). O perfil vem primeiro, porque determina tudo o que vem a seguir, e o indicador existe precisamente para tornar finito um segundo passo longo.

Ensinar o produto em vez de o anotar

Os tooltips assumem que o utilizador sabe passar o rato por cima, e o hover não existe no toque. Escolhi um percurso guiado curto para seniores — seis passos que cobrem boas-vindas, encontrar um acompanhante, fazer uma reserva, falar com o acompanhante, o perfil e onde obter ajuda — apresentado como sequência com indicadores de posição, para que a pessoa saiba sempre quanto falta.

Hierarquia

Uma ação principal por ecrã, expressa num único botão preenchido. Tudo o resto é contornado ou texto simples. Num ecrã que uma pessoa idosa está a ler, se duas coisas parecem igualmente importantes, então nenhuma é.

Cartões como unidade de conteúdo. Reservas, acompanhantes e notificações partilham a mesma anatomia de cartão, para que um padrão aprendido numa parte do produto se transfira para a seguinte.

O estado é sempre uma palavra, nunca apenas uma cor. "A aguardar confirmação", não um ponto âmbar. O daltonismo e a redução da discriminação de cor que vem com a idade apontam para a mesma conclusão, e a etiqueta é mais rápida de ler mesmo para quem não tem nenhum dos dois.

Tipografia

• Inter, com alternativas contextuais ativadas para formas de letra mais limpas
• Base de 17px em vez dos habituais 16. Uma pequena mudança que desloca o sistema inteiro, já que todos os tamanhos a jusante são relativos
• Três tamanhos escolhidos pelo utilizador — 17 / 20 / 23px — aplicados na raiz, para que toda a interface escale em conjunto em vez de um bloco de texto crescer dentro de uma caixa fixa
• Títulos em semibold com tracking apertado; entrelinha generosa no texto corrido

Cor

Violeta profundo como primária, âmbar quente como secundária, sobre branco.

O raciocínio é de posicionamento e não estético. Esta categoria assenta por defeito em verdes clínicos e azuis médicos — cores que leem como instituição, serviço, tratamento. O SeniGo não é um produto médico e não deve pedir emprestada a ansiedade que vem de o parecer. O violeta lê-se como pensado e moderno sem se ler como clínico; o âmbar quente mantém-no humano e é usado com parcimónia para calor e ênfase.

A intenção foi sempre que o SeniGo parecesse um produto de consumo bem feito, e não um serviço camarário. As pessoas que o usam não são doentes.

A paleta passou de verde-azulado para violeta a meio do projeto, exatamente por esta razão.

• Violeta#7C3AEDCor primária
• Violeta escuro#6D28D9Cabeçalhos e gradientes
• Âmbar#FCD34DSecundária, usada com parcimónia

Componentes

Construídos sobre primitivas Radix — bases acessíveis de gestão de foco, interação por teclado e ARIA que não queria reimplementar mal. Personalizados para alvos de toque maiores, cantos mais suaves e sombras de baixo contraste em vez de elevação pesada.

Acessibilidade como sistema

Esta é a parte que mais gostaria de ver avaliada, porque está construída e não apenas afirmada.

• Um controlo de acessibilidade permanente e arrastável com três tamanhos de texto e alternador de alto contraste. É arrastável porque qualquer controlo fixo acaba por tapar alguma coisa no ecrã de alguém, e a posição persiste entre sessões.
• O alto contraste é uma substituição completa de tokens, não um filtro. Preto puro sobre branco; bordas escurecidas de cinzento muito claro para cinzento médio, para que as arestas se leiam mesmo; o violeta primário aprofundado para que texto branco sobre ele passe os limiares de contraste; e suavização de fontes desligada, porque o anti-aliasing afina os traços das letras — trabalhando diretamente contra as pessoas que ligaram o modo.
• As preferências persistem. Quem precisa de texto a 23px precisa dele em todas as visitas, e nunca deve ter de pedir duas vezes.
• Anéis de foco visíveis com afastamento em todos os elementos interativos.

Um detalhe que vale a menção por estar exatamente na costura entre UX e engenharia: mudar o tamanho de letra da raiz recalcula todas as medidas relativas da página ao mesmo tempo, o que fazia a interface inteira saltar. A solução é congelar as transições durante dois frames na altura da troca. Uma funcionalidade de acessibilidade que parece avariada quando é usada não será usada uma segunda vez.

Desenhar confiança, visualmente

• Símbolo de verificado em cada cartão e cada perfil
• Nome da instituição como segundo marcador de confiança, independente
• Avaliações acompanhadas de equivalente em linguagem simples — "Excelente" e não apenas cinco estrelas
• Decomposição completa do preço antes de qualquer compromisso
• Uma página de segurança dedicada que explica a cadeia de verificação passo a passo

O protótipo não é um mock clicável — é um produto a funcionar, com base de dados real, autenticação real, pagamentos reais em modo de teste e email real. Todos os fluxos abaixo podem ser percorridos de ponta a ponta.

Essa escolha custou velocidade de iteração visual. O que comprou foi que o design foi testado contra restrições reais: estados de carregamento reais, estados vazios reais, estados de erro reais, e estados de pagamento que só existem quando há mesmo dinheiro envolvido.

Construído para uma data, e para um público

O desenvolvimento tinha um alvo concreto: uma demonstração funcional para levar ao Startup Leiria, a partir do zero em maio de 2026. Essa restrição fez mais pela disciplina de âmbito do que qualquer framework de priorização faria. Uma data fixa e um público ao vivo tornam muito claro, muito depressa, que partes de um produto são estruturais e quais são decoração — e é por isso que a transação ficou terminada antes de a experiência de descoberta ficar bonita.

Fluxos demonstráveis

Sénior — o ciclo principal. Pesquisa com filtros e mapa → abrir um perfil → reservar com preço em tempo real → pagar → receber o serviço → confirmar → avaliar. Inclui o recibo e a cronologia da reserva.

Acompanhante — tornar-se reservável. Registo → perfil → carregamento de documentos → em análise → módulos de formação e quiz → configuração da conta de pagamentos → aceitar um pedido → prestar o serviço → submeter o relatório → receber.

Instituição — gerir uma equipa. Registo → aguardar aprovação → gerir acompanhantes → tratar pedidos de adesão nos dois sentidos → convidar a partir do conjunto de acompanhantes sem instituição.

Administração — operar a plataforma. Rever os documentos submetidos por um acompanhante e aprovar ou rejeitar com justificação → resolver uma disputa em qualquer dos sentidos, incluindo emitir um reembolso real.

Acessibilidade — em tudo. Tamanho de texto e contraste alteráveis a partir de qualquer página, persistindo entre navegação e sessões.

Acesso de demonstração

Um ponto de entrada dedicado autentica o visitante diretamente em contas pré-criadas — uma sénior, uma acompanhante que também gere uma instituição — com um clique e sem registo. Existe precisamente para que o produto possa ser mostrado a quem não vai criar conta para o ver, que é todo e qualquer recrutador e todo e qualquer parceiro potencial.

Primeiro o conceito, o código muito depois

Nove meses separaram a ideia do primeiro commit. Nada foi construído enquanto o modelo central estava errado — e o modelo central estava errado, de uma forma que só ficou clara ao ter de o defender repetidamente perante pessoas sem razão nenhuma para serem simpáticas.

Construir primeiro o marketplace aberto teria significado construir um sistema de verificação, um fluxo de onboarding de acompanhantes e uma história de confiança inteira que teriam todos de ser deitados fora. Mudar de modelo no papel custou meses de reflexão. Mudar depois do lançamento teria custado o produto, e possivelmente pior — o modo de falha de um marketplace de cuidados aberto não é uma má avaliação.

Prefiro ser avaliado por essa contenção do que pela rapidez com que lancei.

Como defini o MVP

Não "um marketplace". O MVP era uma transação completa com a confiança intacta: um sénior encontra alguém, marca, paga, recebe o serviço, confirma que aconteceu, e ambos os lados estão protegidos do princípio ao fim.

Se esse ciclo não fecha, o resto do produto não interessa. Uma experiência de pesquisa bonita ligada a um pagamento que não funciona é uma demonstração, não um produto.

Ordem de construção, e porquê

1. O ciclo de vida da reserva e o pagamento em custódia. A transação é o produto. Tudo o resto a decora.
2. Verificação. No momento em que um produto coloca um estranho dentro de casa de alguém, a verificação deixa de ser funcionalidade e passa a ser licença para operar. Não podia ser fase dois.
3. Descoberta e pesquisa. Só vale quando já há algo que valha a pena encontrar, e é fácil investir demais cedo por ser a parte mais visível.
4. A camada institucional. Saiu da mudança estratégica e redesenhou o roadmap.

Adiado deliberadamente: notificações push, app móvel, interface completa para reservas recorrentes (a recorrência funciona no modelo e cria a reserva seguinte automaticamente, mas tem UI mínima), seguros e analítica.

Compromissos assumidos com consciência

Fricção versus crescimento da oferta. Existem três barreiras entre registar-se como acompanhante e ganhar dinheiro: revisão humana de documentos, um quiz de formação que exige pontuação perfeita, e onboarding da conta de pagamentos. Isto vai travar a oferta, de forma mensurável. Aceitei-o porque, em cuidados, um primeiro mau encontro não custa um utilizador — custa a credibilidade da categoria. Escolhi oferta mais lenta em vez de confiança mais barata.

Custódia versus pagamento imediato. Reter fundos é pior para a tesouraria do acompanhante e acrescenta complexidade operacional real: um registo de pagamento, um webhook, uma máquina de estados, uma tarefa agendada, um processo de disputa. Mas pagar de imediato retira ao sénior a única margem que tem se algo correr mal. Custódia com libertação automática às 48 horas foi o compromisso — proteção de um lado, teto garantido de espera do outro.

Construir a camada institucional antes de haver liquidez de qualquer dos lados. Muita superfície de produto para um marketplace ainda sem utilizadores. A aposta é que as instituições resolvem arranque a frio e confiança ao mesmo tempo, trazendo oferta pré-verificada em grupo e com credibilidade associada. Continua a ser uma aposta.

Mensagens ligadas à reserva. Protegem a plataforma e reduzem a ansiedade do utilizador, ao custo de uma relação continuada mais fraca entre pessoas que já se deram bem.

Desenhar construindo. Iteração visual mais lenta, mas as decisões tiveram de sobreviver a estados reais e não a um caminho feliz.

Utilizadores versus negócio — as tensões honestas

Os utilizadores querem menos fricção; o negócio precisa de fricção de verificação. Resolvido colocando a fricção quase toda do lado da oferta, onde funciona também como sinal de confiança para o lado da procura. O percurso do sénior é deliberadamente curto; o do acompanhante é deliberadamente longo.

O negócio ganha em reservas concluídas; os utilizadores querem levar uma boa relação para fora da plataforma. Depois de um encontro bem-sucedido, a jogada racional para ambos é combinar o próximo em privado e poupar a comissão. Mensagens ligadas à reserva, proteção do pagamento, histórico de avaliações e recibos são a resposta atual. Não é um problema resolvido, e a desintermediação continua a ser a maior ameaça estrutural ao modelo.

O negócio quer receita previsível; as reservas individuais são episódicas. Daí as reservas recorrentes no modelo de dados e os planos de subscrição para instituições — estes últimos hoje posicionamento e não funcionalidade construída.

Roadmap

Agora — tornar o ciclo fiável. Ciclo de reserva, verificação, custódia, disputas, formação, avaliações. Feito.

A seguir — torná-lo utilizável por quem se destina. Testes de usabilidade com pessoas idosas. Contas de familiar/cuidador. Pesquisa com disponibilidade e distância. SMS como alternativa para notificações críticas. Uma resposta real ao arranque a frio de novos acompanhantes.

Mais tarde — torná-lo um negócio. Subscrições institucionais, seguro como produto associado, planos de cuidado recorrente, analítica e relatórios por coorte, app móvel, e expansão cidade a cidade em vez de nacional — a liquidez de um marketplace é local, e uma presença nacional fina vale menos do que uma presença densa numa só cidade.

Tudo nesta secção é raciocínio e hipótese. O produto não foi lançado, e não há utilizadores, transações ou tráfego reais a reportar.

Modelos de receita considerados

1 · Comissão por transação — implementado. Uma taxa de plataforma de 15%, calculada na criação da reserva e retida com o pagamento; o acompanhante recebe 85%. Alinha a receita da plataforma com serviços concluídos e bem-sucedidos, e não com volume de anúncios ou registos. Se os serviços correm mal e são reembolsados, a plataforma não ganha nada — que é o incentivo correto.

2 · Subscrições institucionais — desenhado, não construído. Três escalões com preço por número de acompanhantes ativos, apresentados na página de preços como posicionamento. A lógica: as instituições recebem valor recorrente e previsível — um canal de colocação mais ferramentas de gestão — o que se ajusta melhor a uma subscrição do que a uma comissão por reserva. Daria também ao negócio uma linha de receita que não depende da liquidez do marketplace nos primeiros meses.

3 · Considerados e postos de lado. Subscrição familiar para cuidado recorrente; taxa de verificação cobrada aos acompanhantes (rejeitada — taxar o lado que mais se precisa de fazer crescer); geração de leads para lares; seguro como produto associado, que é provavelmente a melhor segunda linha a longo prazo e aprofunda também a proposta de confiança.

Aquisição — três públicos, três canais

O ponto importante é que estes não são um funil e não devem ser medidos como se fossem.

As instituições não são o melhor canal de oferta — são o canal de oferta. Como o acompanhante chega à plataforma através de uma instituição, angariar acompanhantes é angariar instituições. Isso torna tudo B2B2C e não um marketplace de consumo, e é a consequência mais nítida da mudança de modelo: uma instituição assinada traz vários acompanhantes já verificados e transfere credibilidade para toda a plataforma de uma só vez. É canal de vendas e não self-service, e é por isso que "Sou uma instituição" está como chamada principal na página inicial, com landing page própria por trás.

O compromisso é real e vale a pena dizê-lo: torna o crescimento da oferta mais lento e aos solavancos do que num marketplace aberto, e põe o negócio dependente de um segmento de parceiros que se move a velocidade institucional. Assumi-o deliberadamente em vez da alternativa.

Os acompanhantes continuam a ser alcançados diretamente — por redes informais de cuidadores, escolas de formação e canais sociais — mas o caminho termina numa instituição e não num perfil. O argumento é legitimidade e pagamento garantido: um perfil verificado, um histórico que se acumula, e dinheiro que chega sem ser preciso pedir.

Seniores e famílias são o público mais difícil, porque quem procura é normalmente o filho adulto e quem é servido não. Dois caminhos: pesquisa por intenção, e é por isso que cada acompanhante tem um perfil público indexável com URL próprio e imagem de partilha; e indicação por prescritores — clínicas, farmácias, juntas de freguesia e assistentes sociais, a quem esta pergunta já é feita e que hoje não têm boa resposta para dar.

Confiança e retenção

A confiança é construída antes do registo através da página pública de segurança, dos perfis públicos e das avaliações reais, e reforçada em cada transação através da custódia, dos relatórios de sessão e de um processo de disputa a sério.

Alavancas de retenção que hoje existem: favoritos, histórico de avaliações, reservas recorrentes, recibos e o sistema de notificações. O relatório de sessão é discretamente uma das mais fortes — uma família que acumulou um histórico escrito de cuidado tem algo que a plataforma guarda e um acordo privado não dá.

O risco honesto continua a ser a desintermediação. Quando já existe confiança entre duas pessoas, a plataforma tem de continuar a merecer a sua comissão.

Funil e métricas que instrumentaria

Lado da procura: visualizações de perfil → pedidos de reserva → taxa de aceitação → conclusão do pagamento → conclusão do serviço → taxa de avaliação → reserva repetida em 60 dias.

Lado da oferta: registo → documentos submetidos → taxa de aprovação na verificação → taxa de aprovação na formação → conclusão do onboarding de pagamentos → primeira reserva aceite → tempo até ao primeiro ganho (o número que melhor prevê se um acompanhante fica).

Saúde do marketplace: tempo entre pedido e aceitação; cobertura por cidade e tipo de serviço; rácio entre acompanhantes ativos e seniores ativos; taxa de disputas; e taxa de confirmação automática — se uma fatia elevada de reservas fecha automaticamente em vez de ser confirmada, isso é um problema de usabilidade vestido de operações.

Candidata a north star: reservas concluídas e confirmadas por mês. Só se move quando os dois lados tiveram o que precisavam.

Nenhuma destas métricas tem valores neste momento.

Para este público, acessibilidade e confiança não são duas frentes de trabalho. Um produto que é difícil de ler é também um produto em que é difícil acreditar.

Legibilidade

Base de 17px em vez de 16, três tamanhos escolhidos pelo utilizador até 23px aplicados na raiz para que a interface inteira escale em conjunto, um modo de alto contraste verdadeiro que reescreve os tokens de cor em vez de filtrar a página, e suavização de fontes desligada nesse modo porque o anti-aliasing afina os traços das letras exatamente para quem o ligou.

Simplicidade

Uma ação principal por ecrã. Estado expresso em palavra, não em cor. Formulários que pedem o mínimo em cada fase e adiam o resto. Escolhas apresentadas como opções a reconhecer em vez de campos a compor.

Navegação

Navegação adaptada ao perfil, para que ninguém tenha de olhar para além de meio produto que não foi feito para si. Uma anatomia de cartão consistente entre secções, para que um padrão aprendido uma vez se transfira. Uma introdução guiada em seis passos para seniores em vez de tooltips, porque o hover não é um gesto que exista no toque nem um hábito que se possa assumir.

Linguagem

Português simples em tudo, sem jargão de plataforma. "A aguardar confirmação" em vez de um código de estado. Nada de prestador, de anúncio ou de gig. A palavra acompanhante foi escolhida deliberadamente: já carrega o sentido certo em português, descrevendo uma pessoa e não uma unidade de serviço.

Confiança

Verificação mostrada, não afirmada: uma página pública que explica a cadeia passo a passo — documento de identificação, registo criminal, revisão humana, pagamento em custódia. Símbolo de verificado e nome da instituição em cada perfil. Avaliações com equivalente em linguagem simples. Respostas dos acompanhantes às avaliações, que mostram responsabilização e não apenas reputação.

Segurança

Documento de identificação frente e verso, registo criminal, selfie com o documento, NIF, e revisão humana de tudo isso. Contacto de emergência, necessidades de mobilidade e notas médicas no perfil do sénior, para que o acompanhante chegue informado em vez de a adivinhar. Fundos retidos até o serviço ser confirmado. Um registo de auditoria nos bastidores, e exportação completa de histórico para os pedidos de autoridades que uma plataforma destas acabará por receber.

Transparência e reversibilidade

Decomposição completa do preço antes de qualquer compromisso. Recibos depois. Estado visível em cada fase de uma reserva. Uma janela de cancelamento gratuito de 24 horas anunciada, em vez de uma política descoberta no momento de cancelar. Um caminho de disputa real, com um humano do outro lado.

A regra que mantive do princípio ao fim:

Cada passo que um sénior dá deve ser, ou reversível, ou claramente explicado antes de ser dado.

A confiança é um fluxo, não um símbolo

Comecei a pensar na confiança como algo a mostrar — um símbolo de verificado, boas avaliações, uma página de segurança tranquilizadora. Acabei a entendê-la como algo que o produto faz, distribuído por todo o percurso: o que pede e quando, o que retém, quem tem de concordar antes de o dinheiro se mover, e o que acontece quando alguém diz que correu mal. O símbolo é a parte mais pequena disso.

Fricção no sítio certo é uma funcionalidade

Todos os meus instintos diziam reduzir passos. Este projeto ensinou-me a perguntar passos de quem e o que os passos sinalizam. As três barreiras por que um acompanhante passa tornam o produto mais lento de integrar e materialmente mais seguro de usar — e é precisamente a fricção do lado da oferta que permite ao lado da procura manter-se curto.

Desenhar para pessoas idosas resultou num produto melhor para toda a gente

Tipografia base maior, uma ação clara por ecrã, estado em palavras, linguagem simples, passos reversíveis. Nada disso é pior para alguém de trinta anos. Desenhar para o caso mais difícil levantou o patamar em tudo, e é um argumento que hoje faria em qualquer produto.

Construir ensinou-me quanto custam as minhas decisões de design

A custódia não é um interruptor. É um registo de pagamento, um webhook, uma máquina de estados, uma tarefa agendada, um processo de disputa e uma interface de administração. Saber isso muda a forma como desenho — não por me tornar mais tímido, mas por me permitir dizer que parte de uma proposta é cara e porquê, que é o que torna um designer útil numa conversa de planeamento e não apenas numa revisão.

O utilizador e o comprador nem sempre são a mesma pessoa

A lacuna mais clara que encontrei estava no meu próprio raciocínio, não na interface: o filho adulto que procura, avalia e paga não está modelado em lado nenhum do produto, apesar de ser provavelmente o utilizador mais ativo que tem. Descobri isso a raciocinar sobre o percurso e não sobre os ecrãs, o que é um argumento para começar por aí.

Uma categoria é julgada antes do produto

Um programa de aceleração recusou a candidatura numa fase em que, tanto quanto consegui perceber, só o tema tinha sido lido — não a ideia, nem o produto.

A resposta útil não é discutir com isso. É levá-lo à letra: cuidados a idosos lê-se, num relance, como uma categoria social de baixo crescimento. Se é essa a impressão que só o tema cria, então o posicionamento tem de fazer trabalho a sério antes de alguém chegar sequer ao produto — abrindo com o modelo institucional, a transação em custódia e a economia B2B2C, e não com a demografia.

É um problema de comunicação, e é meu e não de quem lê. Mudou a forma como abro quando descrevo este produto, incluindo neste documento.

Escrever de que pressuposto depende cada decisão

A mudança de marketplace para rede com respaldo institucional só foi possível porque eu tinha escrito o pressuposto da confiança de forma explícita. Quando a lógica da verificação individual falhou, era óbvio o que tinha falhado e o que precisaria de a substituir. Decisões guardadas vagamente na cabeça não se revisitam, só se defendem.

Transformar um problema numa solução digital

A definição do problema sobreviveu intacta a todo o projeto. Quase todas as soluções que construí à volta dela mudaram. É a ordem certa, e é a principal coisa que quero levar para o próximo projeto.

1 · O research é a maior lacuna, e não é por pouco

Sem entrevistas, sem testes de usabilidade, sem sessões com pessoas idosas reais. Tudo o que este case study diz sobre usabilidade para seniores é raciocinado e não observado. Primeira ação: 5 a 8 sessões moderadas com pessoas com mais de 70 anos, nos seus próprios dispositivos, a tentar o fluxo de descoberta → reserva sem ajuda. Esperaria que invalidasse várias decisões que hoje considero boas, e isso vale mais do que confirmação.

2 · O familiar não está modelado

Não há forma de um filho adulto ter conta própria, gerir as reservas de um pai ou receber notificações. Sendo provavelmente o utilizador mais ativo de um produto destes, é a funcionalidade em falta de maior valor e o ponto cego mais claro do meu próprio processo.

3 · A pesquisa não responde à pergunta real

Os filtros funcionam sobre a cidade como texto, não sobre distância ou raio. A disponibilidade semanal existe no modelo de dados mas não é filtrável. A pergunta que uma pessoa realmente tem é "quem me pode ajudar na quinta à tarde, perto de mim" — e neste momento o produto não pode ser questionado assim.

4 · O arranque a frio dos novos acompanhantes não está resolvido

Zero avaliações significa zero reservas, que significa zero avaliações. Um perfil verificado mas vazio compete com perfis estabelecidos e perde sempre. Isto precisa de um mecanismo deliberado — aval institucional mais evidenciado, preço de introdução, um estado novo bem explicado que mostre verificação em vez de histórico, ou uma garantia na primeira reserva.

5 · A acessibilidade precisa de verificação, não de intenção

Sem testes com leitores de ecrã, sem auditoria WCAG formal, sem testes com tecnologia de apoio, e sem testes com utilizadores que dependam mesmo do modo de alto contraste. O sistema foi construído com cuidado, mas cuidado não é o mesmo que verificado, e não reclamaria conformidade sem auditoria.

6 · Os sinais de confiança são unidirecionais

Os seniores avaliam os acompanhantes em profundidade. Os acompanhantes quase nada sabem sobre quem vão encontrar ou onde vão entrar. É uma falha de segurança do lado da oferta, e é o tipo de assimetria que parece bem até um incidente a tornar óbvia.

7 · O build ainda não acompanhou a decisão central

A decisão de produto é que o acompanhante chega à plataforma através de uma instituição. O modelo de dados continua a tratar essa associação como opcional, e o fluxo de onboarding não a pede — neste momento um acompanhante pode ser aprovado e começar a aceitar reservas sem instituição nenhuma por trás.

É a distância entre uma decisão tomada no papel e uma decisão imposta em software, e é o ponto mais importante desta lista a fechar, porque todo o argumento de confiança assenta nele.

8 · A verificação não escala como está

Cada conjunto de documentos é revisto manualmente. Em qualquer volume real, isso é ou um estrangulamento que asfixia a oferta ou um processo feito à pressa — e verificação feita à pressa é pior do que nenhuma, porque nela se confia. Precisa de ferramentas de triagem, pontuação de risco e um caminho de escalamento claro.

9 · As notificações assumem hábitos que este público pode não ter

Apenas email e na aplicação. Uma pessoa idosa pode não ver o email diariamente. Para eventos críticos — reserva aceite, acompanhante a caminho, serviço amanhã — SMS ou chamada telefónica provavelmente não são opcionais.

10 · A página de preços promete algo que não existe

Os planos de subscrição institucionais são apresentados como disponíveis. É um risco de credibilidade exatamente junto do segmento de parceiros de que a estratégia depende, e deve ser construído ou reenquadrado como brevemente.

11 · A política de cancelamento é demasiado grosseira

Um único corte às 24 horas, gratuito antes e impossível depois. As necessidades de cuidado são imprevisíveis dos dois lados. Uma política graduada — taxas parciais, tolerância para cancelamentos tardios, regras diferentes para doença — seria mais justa e reduziria a carga de suporte.

12 · Não há nada instrumentado

Sem analítica, nenhuma das métricas da secção de negócio poderia hoje ser respondida. Antes de qualquer trabalho de crescimento, o funil tem de ser mensurável — a começar pelas taxas de conclusão dos dois fluxos de onboarding, onde esperaria as maiores perdas silenciosas.