UI / UX Design
TRUE AUTHENTIC SELF
0 -> 1. Authenticity that travels with content, not platforms.
Role:
Founding Product Designer
Industry:
Trust & Verification
Team:
Founder, Engineering
Project Duration:
Ongoing
Overview:
True Authentic Self is a mobile app that embeds cryptographic signatures directly into content — capturing who created it, when, where, and whether it's been modified. That signature travels with the content, so authenticity can be verified anywhere it appears, regardless of platform.
As the founding designer, I've been defining this product from the ground up — every flow, every pattern, every system state — for a product category that has no established UX precedent. My work spans content capture and signature customization for creators, signature detection and verification for readers, and the profile system that serves both. Each sprint moves from concept sessions with the founder through lo-fi sketches to hi-fi wireframes, with design reviews conducted directly with him.
The Problem:
Digital content is easy to create and nearly impossible to trust once it leaves its original context. TAS flips the model: authenticity is embedded in the content itself, not dependent on any platform to vouch for it.
That premise introduces a design challenge with no rulebook. There are no established patterns for embedding, detecting, or communicating cryptographic signatures in a consumer mobile product. The system requires a five-step loop — create, embed, export, publish externally, re-link inside TAS — and users arrive expecting content to be immediately usable after creation. Those two things are in direct conflict, and the design had to hold both.
Process:
Because TAS is a genuinely new product category, there was nothing to benchmark against. Research focused on understanding user expectations around trust, transparency, and multi-step flows — specifically, what happens when a system's complexity is invisible to the person using it.
Three findings drove every design decision that followed: users expect immediacy after content creation, and TAS's multi-step model breaks that expectation; flows that span two platforms have significant drop-off risk at every handoff; and when a system's state is unclear, users don't assume complexity — they assume failure. That last one matters most in a trust product. An ambiguous result doesn't just confuse users, it actively undermines the product's core promise.
Design:
TAS serves two user types — creators who sign content and readers who verify it — and each required different mental models built on top of the same underlying system.
On the creator side, the capture experience needed to make signature customization feel like personalization rather than technical configuration. An IG/Snap-style persistent toolbar replaced the original idea of tapping the signature to open controls — a logical contradiction, since the control would move with the signature if position is adjustable. The Draft → Publish system was the most critical piece: content must be externally published before a signature can be verified, which is a real infrastructure constraint, not a bug. Rather than hiding it, I made the system state explicit at every point — drafts visible alongside verified posts, a guided publishing flow that treats the external link as required, and clear feedback at each stage of the lifecycle.
On the reader side, three scanning entry points (in-app camera, camera roll, screen recording) each needed different interaction models but had to feel like one unified system. The verification result has five states — Verified, Author Verified, Unverified, Partial Scan, Not Found — and getting those distinctions right mattered enormously. "Unverified" means the signature is authentic but the publish loop isn't complete yet. "Partial Scan" means a technical error interrupted detection. Conflating them would be a trust failure in a product literally built around trust.
The Solution:
Creators capture content and embed a signature — customizing color, opacity, position, location precision, and anonymity — then complete the verification loop by publishing externally and re-linking inside TAS. Their profile functions as a workspace: drafts with incomplete publish links sit alongside verified posts, so the status of every piece of content is always visible to them.
Readers scan signed content through any of the three entry points and receive a result that communicates what's known, what's uncertain, and what they can do next — with clear recovery paths for every incomplete or failed state. Profiles in TAS aren't searchable. They're discoverable only through scanned content, which is an intentional product decision: you find people through their authenticated work, not a social graph. It reinforces the core premise rather than contradicting it.
Impact & Reflection:
TAS launched as an invite-only MVP in May 2026 and is currently in active testing ahead of public release. The product is live and the role is ongoing.
What this project changed about how I think: not all friction is bad design. In a trust product, some friction is what makes the system feel credible. The real skill was learning when to reduce it and when to preserve it — and sitting with the fact that that tension doesn't resolve cleanly. I came into this project thinking about design as simplification. I'm leaving it thinking about it as legibility. Making a complex system understandable is a different problem than making it simple, and TAS is where I learned that distinction.
More Projects
UI / UX Design
TRUE AUTHENTIC SELF
0 -> 1. Authenticity that travels with content, not platforms.
Role:
Founding Product Designer
Industry:
Trust & Verification
Team:
Founder, Engineering
Project Duration:
Ongoing
Overview:
True Authentic Self is a mobile app that embeds cryptographic signatures directly into content — capturing who created it, when, where, and whether it's been modified. That signature travels with the content, so authenticity can be verified anywhere it appears, regardless of platform.
As the founding designer, I've been defining this product from the ground up — every flow, every pattern, every system state — for a product category that has no established UX precedent. My work spans content capture and signature customization for creators, signature detection and verification for readers, and the profile system that serves both. Each sprint moves from concept sessions with the founder through lo-fi sketches to hi-fi wireframes, with design reviews conducted directly with him.
The Problem:
Digital content is easy to create and nearly impossible to trust once it leaves its original context. TAS flips the model: authenticity is embedded in the content itself, not dependent on any platform to vouch for it.
That premise introduces a design challenge with no rulebook. There are no established patterns for embedding, detecting, or communicating cryptographic signatures in a consumer mobile product. The system requires a five-step loop — create, embed, export, publish externally, re-link inside TAS — and users arrive expecting content to be immediately usable after creation. Those two things are in direct conflict, and the design had to hold both.
Process:
Because TAS is a genuinely new product category, there was nothing to benchmark against. Research focused on understanding user expectations around trust, transparency, and multi-step flows — specifically, what happens when a system's complexity is invisible to the person using it.
Three findings drove every design decision that followed: users expect immediacy after content creation, and TAS's multi-step model breaks that expectation; flows that span two platforms have significant drop-off risk at every handoff; and when a system's state is unclear, users don't assume complexity — they assume failure. That last one matters most in a trust product. An ambiguous result doesn't just confuse users, it actively undermines the product's core promise.
Design:
TAS serves two user types — creators who sign content and readers who verify it — and each required different mental models built on top of the same underlying system.
On the creator side, the capture experience needed to make signature customization feel like personalization rather than technical configuration. An IG/Snap-style persistent toolbar replaced the original idea of tapping the signature to open controls — a logical contradiction, since the control would move with the signature if position is adjustable. The Draft → Publish system was the most critical piece: content must be externally published before a signature can be verified, which is a real infrastructure constraint, not a bug. Rather than hiding it, I made the system state explicit at every point — drafts visible alongside verified posts, a guided publishing flow that treats the external link as required, and clear feedback at each stage of the lifecycle.
On the reader side, three scanning entry points (in-app camera, camera roll, screen recording) each needed different interaction models but had to feel like one unified system. The verification result has five states — Verified, Author Verified, Unverified, Partial Scan, Not Found — and getting those distinctions right mattered enormously. "Unverified" means the signature is authentic but the publish loop isn't complete yet. "Partial Scan" means a technical error interrupted detection. Conflating them would be a trust failure in a product literally built around trust.
The Solution:
Creators capture content and embed a signature — customizing color, opacity, position, location precision, and anonymity — then complete the verification loop by publishing externally and re-linking inside TAS. Their profile functions as a workspace: drafts with incomplete publish links sit alongside verified posts, so the status of every piece of content is always visible to them.
Readers scan signed content through any of the three entry points and receive a result that communicates what's known, what's uncertain, and what they can do next — with clear recovery paths for every incomplete or failed state. Profiles in TAS aren't searchable. They're discoverable only through scanned content, which is an intentional product decision: you find people through their authenticated work, not a social graph. It reinforces the core premise rather than contradicting it.
Impact & Reflection:
TAS launched as an invite-only MVP in May 2026 and is currently in active testing ahead of public release. The product is live and the role is ongoing.
What this project changed about how I think: not all friction is bad design. In a trust product, some friction is what makes the system feel credible. The real skill was learning when to reduce it and when to preserve it — and sitting with the fact that that tension doesn't resolve cleanly. I came into this project thinking about design as simplification. I'm leaving it thinking about it as legibility. Making a complex system understandable is a different problem than making it simple, and TAS is where I learned that distinction.
More Projects
UI / UX Design
TRUE AUTHENTIC SELF
0 -> 1. Authenticity that travels with content, not platforms.
Role:
Founding Product Designer
Industry:
Trust & Verification
Team:
Founder, Engineering
Project Duration:
Ongoing
Overview:
True Authentic Self is a mobile app that embeds cryptographic signatures directly into content — capturing who created it, when, where, and whether it's been modified. That signature travels with the content, so authenticity can be verified anywhere it appears, regardless of platform.
As the founding designer, I've been defining this product from the ground up — every flow, every pattern, every system state — for a product category that has no established UX precedent. My work spans content capture and signature customization for creators, signature detection and verification for readers, and the profile system that serves both. Each sprint moves from concept sessions with the founder through lo-fi sketches to hi-fi wireframes, with design reviews conducted directly with him.
The Problem:
Digital content is easy to create and nearly impossible to trust once it leaves its original context. TAS flips the model: authenticity is embedded in the content itself, not dependent on any platform to vouch for it.
That premise introduces a design challenge with no rulebook. There are no established patterns for embedding, detecting, or communicating cryptographic signatures in a consumer mobile product. The system requires a five-step loop — create, embed, export, publish externally, re-link inside TAS — and users arrive expecting content to be immediately usable after creation. Those two things are in direct conflict, and the design had to hold both.
Process:
Because TAS is a genuinely new product category, there was nothing to benchmark against. Research focused on understanding user expectations around trust, transparency, and multi-step flows — specifically, what happens when a system's complexity is invisible to the person using it.
Three findings drove every design decision that followed: users expect immediacy after content creation, and TAS's multi-step model breaks that expectation; flows that span two platforms have significant drop-off risk at every handoff; and when a system's state is unclear, users don't assume complexity — they assume failure. That last one matters most in a trust product. An ambiguous result doesn't just confuse users, it actively undermines the product's core promise.
Design:
TAS serves two user types — creators who sign content and readers who verify it — and each required different mental models built on top of the same underlying system.
On the creator side, the capture experience needed to make signature customization feel like personalization rather than technical configuration. An IG/Snap-style persistent toolbar replaced the original idea of tapping the signature to open controls — a logical contradiction, since the control would move with the signature if position is adjustable. The Draft → Publish system was the most critical piece: content must be externally published before a signature can be verified, which is a real infrastructure constraint, not a bug. Rather than hiding it, I made the system state explicit at every point — drafts visible alongside verified posts, a guided publishing flow that treats the external link as required, and clear feedback at each stage of the lifecycle.
On the reader side, three scanning entry points (in-app camera, camera roll, screen recording) each needed different interaction models but had to feel like one unified system. The verification result has five states — Verified, Author Verified, Unverified, Partial Scan, Not Found — and getting those distinctions right mattered enormously. "Unverified" means the signature is authentic but the publish loop isn't complete yet. "Partial Scan" means a technical error interrupted detection. Conflating them would be a trust failure in a product literally built around trust.
The Solution:
Creators capture content and embed a signature — customizing color, opacity, position, location precision, and anonymity — then complete the verification loop by publishing externally and re-linking inside TAS. Their profile functions as a workspace: drafts with incomplete publish links sit alongside verified posts, so the status of every piece of content is always visible to them.
Readers scan signed content through any of the three entry points and receive a result that communicates what's known, what's uncertain, and what they can do next — with clear recovery paths for every incomplete or failed state. Profiles in TAS aren't searchable. They're discoverable only through scanned content, which is an intentional product decision: you find people through their authenticated work, not a social graph. It reinforces the core premise rather than contradicting it.
Impact & Reflection:
TAS launched as an invite-only MVP in May 2026 and is currently in active testing ahead of public release. The product is live and the role is ongoing.
What this project changed about how I think: not all friction is bad design. In a trust product, some friction is what makes the system feel credible. The real skill was learning when to reduce it and when to preserve it — and sitting with the fact that that tension doesn't resolve cleanly. I came into this project thinking about design as simplification. I'm leaving it thinking about it as legibility. Making a complex system understandable is a different problem than making it simple, and TAS is where I learned that distinction.