You expose privacy every time you share a phone number, most people do it dozens of times a year

With no way to revoke, expire, or limit what they've given away. This project rebuilt that assumption from the ground up.

01 • Context & Problem

Static identity in a contextual world

Most people already share different information in different situations, they just don't have tools that support it.

This isn't a niche privacy concern. It's the gap between how people think about sharing and what current tools actually let them do. The gap isn't awareness, it's infrastructure.

Situation	What people actually want to share
Industry conference	Work email, LinkedIn
Social event	Instagram, maybe a number
Quick IRL meetup	Something temporary, just for now
Strangers nearby	As little as possible, or nothing

Existing privacy tools solve the wrong problem. They focus on encryption and backend security, but users think in simpler terms: What can people see about me, and for how long?

Three specific problems made this worth solving:

02 • My Role

End-to-end ownership, founder-level collaboration

The core Qi concept came from the founding team. Everything else, the identity system, the interaction model, the creation and lifecycle flows, the multi-channel sharing architecture, I designed from scratch. This meant moving between product strategy and pixel-level decisions on the same day.

I worked closely with the CEO to pressure-test the model conceptually, and with the frontend engineer to ensure the system could actually be built as designed. A lot of the important decisions happened at that intersection.

Collaborators: CEO Frontend Engineer

03 • Design Challenges

Designing something without a reference point

Flexibility vs. simplicity

Configurable enough to be useful. Simple enough to use in 30 seconds.

A Qi can include multiple contact fields, visibility rules, expiration windows, and discovery settings. The configuration space is large. The risk was creating something that felt more like a permissions dashboard than a social tool, especially for a product meant to be activated right before walking into a room.

Lifecycle behavior

When a Qi changes, what happens to people who already have it?

If a Qi behaves like a live profile, updates propagate instantly, powerful, but unpredictable from the sharer's perspective. If it behaves like a snapshot, it's more trustworthy but harder to maintain. Neither model was obviously right. The answer was a product values question about what kind of trust Cirqil was building, not a technical one.

Trust without precedent

How do you build user trust for a concept that has never existed before?

Users had no prior experience with temporary identity. Communicating how a Qi behaves, what it shares, who can see it, when it ends, had to happen through the product itself. There was no shorthand to borrow, no "like X but for Y" that would land.

Multi-context interaction

The same identity system needs to work across Bluetooth, NFC, and direct link sharing.

Different real-world situations call for different sharing mechanics. Designing one mechanism and forcing all contexts through it would have broken the core promise. Each channel needed its own interaction model, ambient, intentional, or asynchronous, without fragmenting the overall experience.

04 • Key Decisions

Four decisions that defined the system

Frame creation around intent, not configuration

Early wireframes surfaced every option upfront, fields, visibility, expiry, discovery settings. It was complete. It was also exhausting.

The shift was reframing the flow around three questions users naturally ask. This reframe didn't reduce flexibility, advanced controls are still accessible, but it changed the mental model from "configure privacy settings" to "set up a social identity." That distinction matters for whether anyone actually uses it.

Intent question	Maps to
What do you want to share?	Contact fields
In what situation?	Context / Qi name
For how long?	Expiration

Draft Qi versus active discoverable state

Separate creation from activation

A created Qi is not the same as an active Qi. Users can build one in advance without becoming discoverable, and activate it only when ready.

This does two things: it prevents accidental exposure, a real concern for a privacy tool, and it reinforces the intentional nature of sharing, which is core to Cirqil's value proposition. It also mirrors how people actually behave. You decide what to share before you walk into the room.

Design for the context, not just the feature

Different real-world situations call for different ways of connecting. Rather than designing one sharing mechanism and forcing all contexts through it, I designed three distinct modes. The interaction model varies by channel, Bluetooth is ambient and opt-in, NFC is deliberate and instant, username is persistent and low-friction. Matching the mechanic to the context was as important as the feature itself.

Channel	Mechanic	Best for
Nearby Discovery	Bluetooth, passive	Events, open networking
NFC Tap	Instant, intentional	Quick one-to-one exchange
Username / Link	Persistent, low-friction	Remote or async connections

Conference Qi
What matters?	Context
Shares	Work email + LinkedIn
Visibility	Within 20 meters
Expires	End of event
Discovery	Bluetooth

Social Event Qi
What matters?	Context
Shares	Instagram only
Visibility	Nearby
Expires	In 2 hours
Discovery	Bluetooth + NFC

Expiration as a trust primitive

The core lifecycle question was whether a shared Qi should behave as a live profile or a snapshot.

Making expiration the anchor, not just a setting, meant users could reason about their identity simply: "It will stop being visible when I say it does." That predictability is what makes the system feel safe enough to actually use.

The insight: users don't need total control over every variable. They need one thing they can count on. Expiration is that thing.

05 • Outcome

A complete system, ready to build

By the time the team paused, the design was complete, end-to-end flows for creation, activation, discovery, connection, and expiration, across all three sharing channels. The system held up conceptually and was spec'd for development.

Cirqil identity system: end-to-end flows for Qi lifecycle and sharing channels from dev-ready specs.

🏗️ System design

Full identity lifecycle defined, from Qi creation through expiration, including edge cases and update behavior.

🤝 Interaction model

Three distinct sharing channels designed to match real-world contexts, not force all usage through a single pattern.

📐 Dev-ready specs

Polished screens and specs delivered before the team paused, ready to hand off when the project restarts.

The team paused due to internal circumstances. The founder is actively seeking funding to restart development. The design system is complete and preserved, this project isn't finished, it's waiting.

06 • Reflection

What this project changed about how I design

Cirqil was a different kind of problem. There were no comparable products to reference, no established patterns to adapt. The hardest work wasn't visual, it was defining how a system should behave before I could design how it should look.

01, The interaction model is the product. For Cirqil, getting the screens right was downstream of getting the lifecycle model right. The live vs. snapshot decision shaped every creation flow, every update interaction, every expiration state. Spending time on that before touching UI wasn't slowing down, it was the actual design work.

02, Simplicity is about sequencing, not subtraction. I didn't remove features to make Qi creation feel simple. I changed the order and framing of decisions, surfacing intent-based questions first and deferring configuration to secondary flows. The system stayed just as capable; users just encountered its complexity at the right time.

03, Trust comes from predictability, not just privacy. A system can be technically private but still feel unsafe to use if users can't predict how it behaves. Making expiration the one guaranteed anchor, the thing that always works, always ends access, gave the system a foundation users could reason about. That's a product values decision as much as a design one.