Defining the presence

The first version of the idea was a digital business card built around a Profile. A professional shares it through a link, QR code or physical product, and someone opening it can save their contact details.

But even a digital business card sits next to a surprising number of other products.

People might want to save Profiles they find interesting. They might want to discover professionals they have never met. Companies might want CRM integrations. A richer Profile could start looking like a small website. Add a feed and the product starts moving towards social media.

Not a social network

Social features were one of the directions I considered early on. Discovery made sense, as did having a way to save Profiles, but I did not want to build a feed, followers, likes or other mechanics around relationships between users.

The focus was on helping people present themselves and their work, and giving them ways to share that presence.

As the product took shape, I started describing it as a marketing tool. It gave me a reference point to return to whenever another reasonable feature started pulling the product in a different direction.

Building the Profile

A name, photo, title and contact details may be enough for a digital business card. But if the Profile was going to be more than that, I had to decide what else someone might need to present themselves.

The answer depended on who that person was.

A photographer may want to show previous work. A consultant may present services. A designer may show projects. A small business may have products. Modeling each profession separately would make the product increasingly specialized. Making the Profile completely configurable could create the opposite problem.

Many of the options made sense on their own. A little more flexibility here or another section there would start pushing the Profile closer to a website builder.

So instead of designing a different Profile for each type of user, I started looking for the parts that could work across them.

Some were straightforward. Most people need a way to introduce themselves, highlight what matters and make it easy to get in touch. Other needs were more specific, but could still share a structure.

Showcase came from that. Work, services, projects and products mean different things to the people presenting them, but the product does not necessarily need a different model for each one.

However, not everything needed to fit a shared model.

For example, testimonials were different because their purpose was specific. They add trust to a professional presentation. Making them public reviews would also change who has control over that part of the Profile. Keeping them as Testimonials lets the Profile owner decide what appears there.

The sections gave the Profile a structure, but they did not need to make every Profile look the same.

Every Profile starts with a Hero. The rest depends on what someone needs to present. Other sections can be added, removed and reordered. Someone may want Showcase near the top, while someone else may care more about About or Testimonials.

The user decides what belongs on the Profile and in what order. They do not have to decide how those sections behave across different screen sizes or how the page should be laid out. That stays with the product.

This was also why I did not want to start from a blank canvas. Faced with an empty page, the user first has to figure out where to start and what the page should contain. The people using the product should not need to know how to design a website in order to build a good Profile.

I also limited how much content some sections could contain. Testimonials, Highlights and Accordion items would have a maximum number of entries, even though the database could store far more.

I would not want someone to put fifty testimonials on a Profile just because the system can render them. At some point more testimonials stop adding much. A long list of Highlights stops feeling like highlights, and an Accordion with dozens of items starts becoming something else entirely.

So I kept coming back to the same question. Which decisions need to belong to the user, and which should belong to the product?

When the customer is an organization

The Profile already made sense for an individual professional or a small business. Not everyone needs a custom website with a CMS and ongoing maintenance. For some, a Profile they can maintain themselves may be enough.

An established organization is different. It probably already has a website, social channels and a marketing or PR function. Giving it another small website is not much of a proposition.

Things got more interesting when I looked at the people representing an organization.

A company may have dozens of salespeople, consultants or other professionals who each need their own presence. Each Profile should still represent the individual. They may have their own photo, experience, work or testimonials.

At the same time, some information does not really belong to the individual. The company may want to control its branding, shared company information and other values that should remain consistent across the Profiles it manages.

At first, supporting organizations looked like a matter of grouping more Profiles together. Giving the organization some control over the Profiles made the model more complex. I also had to separate the person from the organization they belonged to.

Workspace groups Profiles. It also provides the context for who owns and manages them.

The person and the organization also need to remain separate. An Account represents the person and their identity in the product, while Workspace represents an organization they can belong to. A person can have their own Profiles, use their own Account to join a Workspace and potentially belong to more than one organization.

Membership only gives them a relationship with that Workspace. It does not automatically give them control over every Profile or resource the organization owns.

Removing a member from a Workspace should end their organizational access. It should not remove their Account, their personal Profiles or their membership in another Workspace.

For an individual, the value may be having a professional presence without building and maintaining a website.

For an organization, it is different. The value is being able to distribute a controlled professional presence across many people without giving up control of what belongs to the organization.

Around the Profile

Some people want to share their Profile with people they already know. Others also want to be found. Discovery could make Profiles searchable for people who choose to be discoverable, without requiring followers, feeds or a social graph.

Helping someone find a photographer, consultant or designer does not mean the product has to become a marketplace for hiring them. Discovery could help people find existing Profiles without taking ownership of what happens between them afterwards.

Finding someone also created another need. A person may want to find that Profile again later or remember why it was relevant.

Saving a Profile seemed straightforward until I tried to define what “saving” actually meant. Was I saving the person and their contact details, which starts looking like an address book? Was I creating a relationship between two users, which moves back towards social features? And if I added notes and context, how far was that from a small CRM?

Saving a Profile does not need to create a social relationship, and it does not need to turn the product into another address book or CRM. Contact details can stay in the systems people already use for contacts. What matters here is being able to find the Profile again and, if needed, keep some private context about why it was saved.

Insights belonged for a different reason.

If the product was going to be a marketing tool, helping someone distribute their Profile without helping them understand that distribution would leave out an important part of the value.

A view is one signal, but there is more the product can learn from the path around it. Someone may arrive through a shared link, a QR code or a physical product. They may explore the Profile, use a contact action or follow an external link. Over time, those signals can help the Profile owner understand where attention is coming from and which ways of sharing are generating interest.

The product can observe a contact action, but not whether a real conversation happened afterwards. It can observe an external link click, but without information from the other system, it cannot know whether that visit became a booking, purchase or another conversion.

Insights can use the data the product actually has for attribution, without claiming outcomes it cannot observe.

Getting to the Profile

A Profile has a public link and a QR code for sharing. Someone with a supported physical card or tag can also activate it and connect it to a Profile.

Behind that, the different ways of reaching a Profile have lifecycles of their own.

A physical product can exist before anyone activates it. Once activated, it can belong to an Account or Workspace without being connected to a Profile yet. It can later be connected, disconnected or moved to another Profile without the physical product itself changing.

QR codes worked differently. Someone may download one, print it on a business card or place it somewhere else outside the product. If the Profile's public slug changes later, replacing every QR that has already been distributed is not realistic. The old QR still needs to reach the same Profile.

Making QR codes and physical products part of the Profile would tie their lifecycles to it.

I needed something stable behind them, with its own identity and a connection to wherever it should lead.

Internally, I modeled it as an Access Point.

An Access Point can stay the same while its connection changes, giving the system a stable resource behind a QR code or physical product without making it another thing the user has to manage.

From the user's perspective, it is still their Profile QR or their physical product. Access Point is a concept the system needs, not one the interface needs to teach them.

Shaping the product

Defining the product as a marketing tool gave me a direction, but it did not settle every decision. Many of the features I considered made sense on their own, but not all of them fit the product I was defining.

Some decisions removed concepts. Others introduced them.

By the end, it had moved well beyond the digital business card I started with, but its purpose was clearer. More importantly, I had a better way to judge whether a new feature belonged in the product.