Vin a alguén probar un panel de instrumentos que me trouxeron para corrixir. cero erros. tempos de carga subsegundos. Cada característica funcionou exactamente como estaba deseñado. Clicaron arredor durante dous minutos, despois pecharon a pestana e dixeron: "Está roto". Pregunteille que característica. "Non roto roto. Só... inacabado? non sei. Non se sente real." Como un PDF que imprime ben pero non se abrirá en Mac - tecnicamente funcionando, experiencialmente roto. Levoume tres clientes máis e demasiadas entrevistas de usuarios para descubrir o que significaban. Traballar non é o mesmo que sentir que funciona. ⸻ Cando os 400ms eran demasiado rápidos para confiar Unha plataforma de análise B2B que fun contratado para auditar. consultas rápidas. datos precisos. gráficos limpos. Churn subindo cada cuarto. as enquisas de saída seguían dicindo: "Atopamos algo máis fiable". Máis fiable que o que? As súas consultas devolveron en 400 milisegundos. Inrazoablemente rápido. Suspiciosamente rápido. O tempo de execución foi de 99.4%. O competidor que probei? As consultas levaron 3-5 segundos. Pero o competidor mostrou barras de progreso. Estados de carga. "Procesar a súa solicitude..." cun girador animado que se sentiu importante. O produto do cliente? Resultados case instantáneos que apareceron tan rápido que os usuarios asumiron que estaban cached ou incompletos. Ningunha indicación de que algo pasara. Perderon tres negocios empresariais nun cuarto a ese produto máis lento. $ 240K ARR desapareceu. todo pechado no mesmo cuarto. O gasoduto secou. Os tres prospectos dixeron o mesmo nas chamadas de retroceso: "O teu sentíuse demasiado rápido para ser real". Engadín retrasos artificiais de 2 segundos con indicadores de progreso. "Procesar os teus datos..." cun girador. As mesmas consultas de 400ms debaixo, só honesto sobre o traballo que está a suceder. Próximo trimestre: pechado dous acordos contra o mesmo competidor. Ambos os prospectos mencionaron "sentirse máis confiados na calidade dos datos" nas entrevistas post-venda. Os mesmos datos, diferentes sinais de confianza. $160K recuperado. O fundador deixou de abrir demostracións competidoras durante as chamadas de vendas. dixo que finalmente confiou no seu propio produto. Resulta que os usuarios confían en cousas que admiten que están a pensar. ⸻ Auto-save é gaslighting con boas intencións Diferente cliente: un editor de documentos. Auto-salva cada toque de tecla. sincronización en tempo real entre dispositivos. Nunca perdeu un único personaxe na produción. As entradas de soporte seguían preguntando: "Os meus cambios salvaron?" O xestor do produto mostroume os billetes. Centos deles. "Como sei que se gardou?" "Onde está o botón gardar?" "Fixen cambios pero non vexo confirmación." Pregunteille cando eliminaron o botón gardar. El dixo: "Hai dezaoito meses. Auto-save fíxoo obsoleto. Vin a alguén escribir tres parágrafos, pausar, mirar ao redor da interface durante 12 segundos, pechar a pestana sen publicar.Seguinte sesión: o mesmo usuario, reescribiu o mesmo contido, aínda non puido atopar confirmación de que era real. Os usuarios estaban a experimentar escribir nun baleiro sen ningunha evidencia de que algo persistise. Engadín un indicador de "Saveed". Tiny. Faded en despois de cada toque de tecla. "Save..." mentres se sincroniza. "Todos os cambios foron gardados" cando se fixo. menor adición de UI posible. Enviado o martes. Os billetes de soporte sobre o estado de aforro caeron 89% ata o venres. O produto non se fixo máis fiable. Eu só deixara de fingir que a fiabilidade era obvia. Seis meses máis tarde, outro cliente. Produto similar de salvamento automático, aínda en desenvolvemento. Mostrei ao fundador estas gravacións de sesión do primeiro proxecto. Engadiu o indicador "Salvado" antes do lanzamento. Zero boletos de soporte sobre aforros nos primeiros tres meses. Esa é a diferenza entre corrixir problemas e evitalos. A velocidade non é confianza.O proceso visíbel é confianza.Os usuarios non queren instantes - queren probas de que algo ocorreu. ⸻ Facer os produtos máis lentos no propósito Despois do cuarto cliente co mesmo problema de confianza, comecei a engadir retrasos intencionais. Non erros - pausas artificiais que mostran o traballo ocorrendo. Fai clic en enviar? Espere 600ms, mostre spin, a continuación, confirme. Cargue datos? Mostre pantallas esqueléticas mesmo cando a consulta rematou en 300ms. (Productos fabricados tecnicamente máis lentos. Os billetes de soporte sobre "¿Funciona isto?" caeron 40-60% en tres implementacións. A outra cousa: fago erros suficientemente específicos para actuar. "enderezo de correo-e inválido" bate "Algo correu mal." "Tempo do servidor - intenta de novo en 30 segundos" bate "Erro." Os usuarios poden xestionar problemas. ⸻ Tres probas que revelan o que os fundadores non poden ver Despois de catro proxectos onde "sentirse roto" significaba "interface non sinala o que está a suceder", desenvolvín tres diagnósticos que executo antes de deseñar calquera cousa. Custa aos clientes 2 horas de antelación. 
 
 
 
 
 
 
  Show someone the product for five seconds. Not interactive – just looking. Ask: "Does this feel finished?" The five-second impression test. Hesitation means something signals incomplete. "It looks fine but..." means they're sensing interaction gaps. Immediate yes? Watch their face, not their words. (People lie to be polite. Faces don't.) 
 
 
  Throttle the connection. Use the product. Does it explain what's happening? Or just sit there looking frozen? The broken internet test. Most products optimize for perfect conditions. Users experience broken networks, slow servers, congested CDNs. This is where "too fast" products die hardest – zero explanation when infrastructure fails. 
 
 
  List every possible state for every interactive element. Default, hover, focus, active, disabled, loading, error, success. Design all of them. The state audit. Some products design three states and ship with seven. The missing four just... happen. Usually badly. Execute estas no seu produto esta semana. Se atopa estados perdidos ou accións silenciosas, corrixilas antes de construír novas características. ⸻ Os problemas de confianza non xeran erros Están a describir problemas de interface usando linguaxe de funcionalidade. "rupto" significa "non se comporta como espero que as cousas fiables se comporten". Cousas fiables confirman accións. Mostrar progreso. Explicar erros. Un produto pode funcionar perfectamente detrás das escenas, pero se a interface non sinala que funciona, os usuarios experimentan o silencio como un fracaso. Os problemas de confianza non aparecen nos rexistros de erros. Aparecen nas enquisas que din "atoparon algo máis fiable". Normalmente, mentres os rexistros de erros permanecen perfectamente limpos, inútil.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This story contains new, firsthand information uncovered by the writer.

Free Discovery Call with Me

SaaS Design Projects 

UX\UX Agency London

UI/UX Design Services

Digital Product Design Services

Este audio está producido na lingua orixinal da historia!

Por que os bos produtos se senten rotos

About Author

COMENTARIOS

Etiquetas colgantes

ESTE ARTIGO FOI PRESENTADO EN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Product Management Community!

HackerNoon Decoded 2024: Celebrating Our Writing Community!

R Systems BlogBook—Chapter 1: Round 3 is Now Open for Submissions🎉

HackerNoon Decoded 2024: Celebrating Our Remote Work Community!

HackerNoon Decoded 2024: Celebrating Our Product Management Community!

HackerNoon Decoded 2024: Celebrating Our Writing Community!

R Systems BlogBook—Chapter 1: Round 3 is Now Open for Submissions🎉

HackerNoon Decoded 2024: Celebrating Our Remote Work Community!

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps