Import first
Start from the address book a person already maintains.
KnowMe · 2022 · Freelance
I designed a private contacts hub, then learned the concept needed a smaller first bet.
KnowMe brought contact import, duplicate cleanup, richer identity records, and card sharing into one mobile product. I delivered the work in full. It was not built after the client faced a funding shortfall.
01
A private contacts hub tried to replace several fragmented tools.
The client believed a contact should be more useful than a name and phone number stored in a native address book.
People could have duplicate records, business details in one place, social identities in another, and no simple way to share a personal or professional card. KnowMe was intended to consolidate those jobs. A person could import an existing address book, clean it up, create richer records, organise groups, and exchange selected information from one mobile product.
Privacy was part of the proposition, not a settings afterthought. The concept promised not to mine, sell, or share contact data. That made the product tension clear: KnowMe needed enough permission and information to become useful without behaving like the connection products it was trying to replace.
02
I had sole ownership, a short engagement, and no launch feedback to hide behind.
I worked directly for a Canada-based startup for roughly three to four months as the sole designer.
I owned research, synthesis, product flows, low-fidelity wireframes, high-fidelity mobile design, visual direction, and handoff. The breadth of the idea was the main constraint. The product could cover contact storage, duplicate management, groups, nearby discovery, custom cards, subscriptions, payments, and referrals. I had to decide which moments deserved detail while one design engagement carried the whole product story.
The work was delivered, but the client did not proceed to build after a funding shortfall. There is no usage, retention, or commercial outcome to claim. This case study therefore shows the decisions in the design and the limits I can now see in them.
03
Research turned an all-in-one premise into four concrete priorities.
I used a survey of approximately 20 participants, user interviews, a provisional persona, and a direct competitor review to make the broad proposition more specific.
The surviving research material consistently points to four needs: carry existing contacts across without rebuilding them, remove duplicate records, share a selected identity or card, and retain control over personal data. The competitor audit also showed a crowded category. Individual products handled digital cards, scanning, or contact management well, but the client wanted one product to combine the jobs.
I used those signals to focus the main journey on import, cleanup, and controlled sharing rather than asking a new user to create an empty network. The original deck also contained four precise percentages whose basis could not be reconstructed. I omitted them instead of presenting uncertain arithmetic as evidence.
Merge duplicates
Make cleanup visible while its value is easy to understand.
Multiple identities
Let a person decide which details belong on each card.
Explicit visibility
Keep discovery and sharing under the user’s control.
04
I made setup lighter, cleanup immediate, and the overall scope too broad.
The most useful evidence in this project is not the process map. It is where the design accepted friction, where it removed it, and where I should have reduced the product sooner. Those choices reveal both the strongest design logic and its central strategic weakness.
I imported before asking people to rebuild.
I chose a permission-led import from the phone’s address book and rejected an empty-account start. Manual recreation would have made KnowMe prove its value only after demanding substantial effort. Import reduced setup, but it moved a sensitive permission request close to the start and increased the burden on trust copy.
I put duplicate cleanup inside the import sequence.
I surfaced the number of duplicates immediately after import, with clear merge and skip actions. I rejected leaving cleanup only inside settings because the problem was most understandable when the imported list first appeared. The extra step interrupted onboarding, so skipping remained available. A built version would also need a safe review and recovery path before any destructive merge.
I asked for contact depth progressively.
I started a new record with basic identity fields, then exposed work, phone, groups, and additional categories as optional sections. I rejected one long required form. This let simple records stay simple while supporting richer identities. The cost was uneven data depth, which search and filtering would have to handle deliberately.
I kept nearby discovery opt-in.
I designed visibility as a choice between hidden and discoverable rather than making every account publicly findable. That protected the privacy promise and gave sharing a clear user action. It also reduced passive network growth. I accepted that cost because automatic exposure would have contradicted the product’s stated reason to be trusted.
I treated breadth as differentiation for too long.
The feature narrative expanded into groups, messages, nearby discovery, cards, subscriptions, payments, and referrals. I did not narrow that ambition decisively enough. The work became a complete concept, but not a sharp first release. In hindsight, import, merge, and controlled card sharing should have formed the first testable product.
05
The final prototype carried people from an existing address book to richer connection records.
The high-fidelity work covered account creation, contact import, duplicate review, the main contacts list, and flexible record creation.
The screens used familiar mobile patterns so the new value did not require a new interaction language. The important transitions were explicit: permission before import, progress during processing, a review point before merging, and optional depth when creating a contact.
06
It was delivered but not built. I would now prove the smallest valuable loop first.
The funding decision ended the project before build, so the design never faced real permission behaviour, imported data quality, or repeat use.
If I restarted it, I would make the first release narrower: import contacts, review and merge duplicates safely, create one controlled card, and share it. I would validate whether that loop creates enough repeated value before adding groups, nearby discovery, payments, or referrals. I would also bring engineering into import and merge decisions earlier because data permissions and recovery behaviour is product architecture, not finishing details.
The project still shows range across discovery, product structure, mobile interaction, and visual design. Its more important lesson is restraint. A broad vision can help a client see possibility, but a credible product strategy needs a smaller claim that can be tested.
