A Lock Icon Did More for Trust Than Our $6,000 Security Audit
A two-hour UX change taught us that building security and helping people experience it are two different product problems.
We built Immplify to help immigrants manage some of the most sensitive documents they own: passports, visa approvals, work authorizations, tax filings, and immigration records.
These are not ordinary files. If someone loses access to a streaming account, the result is inconvenient. If an immigration document is exposed, misplaced, or compromised, the consequences can be far more serious. It could mean identity theft, a delayed green card, a missed renewal, or an immigration case thrown into chaos.
So when we launched and nearly every one of our first 20 users asked the same question, we were not surprised.
Is my data safe?
We had expected the question, and we had spent months preparing an answer. What we had not understood was that having the right answer was not the same as helping users believe it at the moment that mattered.
We Built the Security First
Before we let a single user into the product, we spent roughly five months building what I thought of as a fortress of real security.
We decided early that we would not maintain a database of user passwords. People would sign up through Google or Apple, which removed the need for us to collect and store their passwords ourselves.
Every document uploaded to Immplify was encrypted. The information parsed from those documents, including names, document numbers, dates, and case IDs, was encrypted at rest. We also implemented tokenization so that sensitive information would not sit in plain text inside our backend systems.
Then we paid $6,000 for an independent security audit. For a bootstrapped company funding the product out of pocket, that was not a small expense. The security firm tested our endpoints, looked for weaknesses, and tried to break what we had built. We addressed the findings, fixed the issues it identified, and received its final report.
It is important to be precise about what that meant. The audit did not create the security of the product by itself. Our engineering controls provided the protection. The audit tested those controls, exposed weaknesses we needed to address, and gave us additional assurance after we made the fixes.
We also published a detailed security page explaining our authentication approach, encryption, tokenization, and audit. We placed it on our landing page so anyone evaluating Immplify could see how seriously we took the responsibility.
From our perspective, we had done what responsible technical founders were supposed to do. We had built the controls, tested them, fixed the weaknesses, and documented the work. We thought we were ready.
It Still Did Not Feel Safe to Users
The questions continued. With only about 20 early users, our feedback process was personal rather than formal. I spoke directly with most of them through onboarding calls, WhatsApp messages, and one-to-one conversations. Before the UX changes, security was the subject that came up almost every time.
People would get excited about what the product could do. They could see the benefit of having their immigration documents and deadlines organized in one place. Then the conversation would reach the point where they had to upload a passport or visa, and their confidence would disappear.
We would explain the encryption. We would describe the audit. We would send them the security page. They would listen and say that it made sense. But when they returned to the product and faced the actual upload screen, the concern came back. A few people needed two or three conversations before they felt comfortable uploading their first document.
At first, we thought this was an education problem. We assumed users did not understand what we had built, so we tried to explain it more clearly and in greater detail. That did not solve the problem.
Hearing an explanation about security and handing over a passport are two completely different experiences. Our users were not evaluating an abstract architecture. They were making a high-risk decision in a specific moment, and the interface gave them no evidence that acknowledged the seriousness of that decision.
There was no single dramatic conversation when we suddenly discovered the answer. The realization developed as we kept hitting the same wall. We had spent months building security, paid real money to have it tested, and repeatedly explained it to users. Yet the same uncertainty returned as soon as they reached the upload step.
Eventually, my co-founders and I stopped looking at the problem from the backend and looked at the screen through the user’s eyes.
What did someone actually see while uploading a passport? A file picker. A progress bar. The word “Uploading.” Then a checkmark. That was it.
The encryption was happening, but it was happening silently. From the user’s perspective, our upload experience looked no different from that of any random application that might not protect the file at all.
The problem was not that Immplify lacked security. The problem was that users could not see or experience the security at the precise moment we were asking them to trust it.
Our Two-Hour Hypothesis
We sat down and identified the points in the product where users were most likely to feel exposed or uncertain. Instead of adding another explanation to the security page, we asked a different question:
How might we make the protection already inside the product visible at the moment users need evidence of it?
We made several changes in one sitting, and the entire implementation took about two hours.
First, we changed the upload state. Instead of displaying “Uploading,” the interface showed “Encrypting Document” beside a lock icon for each file.
This was not a decorative claim. Encryption was already taking place during the upload process. We changed the interface so that it truthfully described what the system was doing. The backend stayed the same, but the experience no longer left users staring at an ambiguous progress bar while wondering what was happening to their passport.
Second, we masked sensitive document numbers on the dashboard. Instead of displaying a complete passport or visa number, we showed only the final four digits and replaced the rest with dots. Users had to select a small lock icon to reveal the complete number.
Third, we placed lock icons near document previews and other sensitive fields. These cues were contextual. They appeared where a user might reasonably wonder whether the application recognized the sensitivity of the information on screen.
Fourth, we changed the interface from warm orange tones to blue. The original palette felt friendly and approachable, but we believed it made the product resemble a casual consumer application. Banks, healthcare platforms, and enterprise tools commonly use blue to communicate stability and seriousness, so we adopted that familiar visual language.
We released all four changes together. We did not run separate experiments or introduce the changes in stages. We had only 20 early users, and an A/B test of every icon, label, interaction, and color would not have produced reliable answers. We saw a recurring problem and shipped what we believed was a coherent response.
Because of that, I cannot honestly say that the lock icon alone changed users’ minds. No user told us, “That icon is what made me trust you.” I suspect the revised upload flow mattered most because uploading was the moment of greatest anxiety, but that is a hypothesis, not something our data proved.
What we observed was the effect of the overall experience.
The Questions Went Quiet
After the changes, the security questions from active users largely stopped. I once described the reduction rate of the questions to be as roughly 90 percent. That number did not come from an analytics dashboard, a structured survey, or a controlled experiment. It was my qualitative estimate based on speaking with our early users almost every day.
Before the changes, security dominated nearly every onboarding conversation, WhatsApp exchange, and follow-up discussion. Afterward, those conversations became rare. The contrast was noticeable enough that the absence of questions became a signal of its own.
Since then, Immplify has grown from roughly 20 early users to more than 1,000, and we still receive very few security concerns. That does not isolate the effect of a particular design element, nor does it transform our early observation into a controlled causal finding. It does suggest that the concern we repeatedly encountered at launch did not persist as the product and its user base grew.
Get Kunal Lall’s stories in your inbox
Join Medium for free to get updates from this writer.
An even more interesting pattern emerged in who continued to ask. The people who stopped raising concerns were generally active users. They had entered the application, uploaded files, seen document numbers masked, and encountered security information at the points where it mattered.
The remaining questions came primarily from prospective users who had not signed up or experienced the product. They were evaluating Immplify from the outside, where the landing page and security article were still their main sources of information.
That distinction changed how I think about trust. A security page can explain your policies. An audit can provide independent assurance. But neither necessarily resolves uncertainty at the moment someone is about to take a risky action. Trust can be formed, strengthened, or lost inside the interaction itself.
Not Every Change Was Cosmetic
At first, I described our work as cosmetic because we did not change the encryption system or rewrite the backend. Looking back, that description is too broad.
The changes belonged to different layers of the product.
The encryption, tokenization, and authentication architecture were technical security controls. They were responsible for protecting information behind the interface.
The independent audit was an assurance mechanism. It tested those controls, helped us identify weaknesses, and gave us a basis for greater confidence after remediation.
The masked document numbers were a protective UX behavior. That interaction did not merely make users feel safer. It reduced the chance that someone walking past an open screen could see a complete passport or visa number. It added a practical privacy safeguard.
The “Encrypting Document” label and contextual lock icons were communication cues. They made an existing technical process visible and showed users that we understood which moments and fields were sensitive.
The blue palette was different again. It was a design interpretation based on familiar visual conventions. No user specifically told us that blue made the application feel safer, and because we released it alongside the other changes, we cannot claim that it independently affected trust. We believed it helped the product communicate greater seriousness, but that remains our judgement rather than a measured conclusion.
These distinctions are important because product teams can easily collapse several different problems into one. A product may have a technical security problem, a privacy problem in the interface, a communication problem, or some combination of the three. Adding a lock icon cannot compensate for weak security. At the same time, strong security hidden completely from users may not help them make a confident decision.
Security Is Also a Product Experience
The lesson I took from this was not that design matters more than engineering, or that a lock icon is more valuable than an audit. The engineering work and the audit addressed whether the product deserved trust. The interface addressed whether users could recognize the reasons to trust it. You need both.
If we had displayed “Encrypting Document” without actually encrypting the document, we would have created security theater. The interface would have been making a promise the product could not keep. That kind of deception is worse than displaying no trust signal at all because users may take risks based on a false belief.
But the inverse also matters. If a company builds a meaningful capability and leaves it invisible, users cannot include it in their decisions. They do not have access to the backend, and most will not read a 1,500-word explanation of encryption standards before trying a product. They judge trust through the evidence available within their experience.
For product managers, this reaches beyond security. Many valuable product qualities are difficult for users to observe directly: reliability, privacy, fraud prevention, data integrity, and the accuracy or limitations of an AI system.
Building those qualities is the first responsibility. The next is deciding when and how to reveal truthful evidence of them.
Making the Invisible Visible
If I were advising another product team facing this problem, I would approach it in four steps.
1. Identify What Users Cannot See
Start with the important work happening behind the interface. If your system protects data, detects fraud, checks an AI-generated answer, preserves a transaction record, or recovers from failure, assume users do not know that capability exists unless the product gives them evidence.
The goal is not to advertise every technical process. It is to identify the invisible quality that affects whether someone is willing to proceed.
2. Find the Moment When That Quality Matters
Trust is contextual. For Immplify, the critical moment was not reading our landing page. It was uploading a passport.
In an AI product, the moment may come when someone is about to act on a recommendation. In a payments product, it may be when the user selects “Send.” In a healthcare application, it may be when someone shares a medical record.
Find the point where uncertainty creates hesitation, abandonment, repeated questions, or avoidance. That is where evidence needs to appear.
3. Show What Is Real
Make the underlying capability understandable without inventing reassurance. Our interface said “Encrypting Document” because the document was actually being encrypted during that process.
The best trust cues reveal genuine system behavior or provide meaningful user control. They do not use familiar symbols to disguise a weak product.
4. Look for a Change in Behavior
We did not survey users to ask whether they felt more secure. Our signal was that the recurring questions nearly disappeared among active users.
Other teams may have better quantitative measures available. Support tickets may decline. Fewer people may abandon a sensitive step. More users may adopt a previously avoided feature. Repeated reassurance requests may become less common.
The measure should match the original expression of uncertainty. If distrust appeared through abandonment, measure abandonment. If it appeared through support requests, track those requests. If it appeared through repeated questions during onboarding, document those conversations rather than converting an impression into a level of statistical certainty the evidence cannot support.
What the Lock Icon Actually Taught Us
Admittedly, a lock icon did not “secure” Immplify, and our early experience does not prove that one icon caused security concerns to fall. Our engineering work created the underlying protection.
The independent audit tested that work, identified weaknesses, and helped us validate the controls after we addressed its findings. Masking document numbers added a practical privacy safeguard. The revised upload language, contextual icons, and visual design made the product’s treatment of sensitive information easier to perceive.
What changed was the relationship between the capability and the experience. We had assumed that if we built security correctly and explained it somewhere on our website, people would understand. They did not. Our users needed evidence at the point where trust became a decision.
At Immplify, that decision carries unusual weight. Our users are navigating one of the most stressful and consequential bureaucratic processes in the world. Their documents are proof of identity, immigration status, and the right to live and work in a country.
Handling those documents responsibly means more than protecting them behind the scenes. It means communicating that protection honestly, clearly, and at the moment a person is being asked to rely on it. That is the larger product lesson.
Building a trustworthy capability and designing an experience through which people can understand that capability are separate responsibilities. Neither replaces the other.
Real security gives trust a foundation. Thoughtful product design gives users truthful evidence that the foundation is there.
Many thanks to Tremis Skeete, Executive Editor of Product Coalition, for his invaluable contributions to this story. A special shout-out to founder Jay Stansell for creating an environment that enhances product management education.
