An invitation to contribute is not permission to finish the family book

We originally imagined the shared family-album editor as a generous product. Everyone invited could add images, replace them, change captions and move pages. One link and one set of controls seemed simpler than asking a group to choose roles. The proposal looked collaborative because no participant was technically excluded from the work. It became less convincing when we watched how people understood the changes being made by someone else.

In research with forty family groups, twenty-six wanted an appointed editor to assemble contributions and fourteen preferred shared editing. The numbers did not establish a universal division of family preferences. They showed that the product was facing more than one legitimate way of working. A person could want to contribute a photograph without deciding where it belonged, while another person could need responsibility for completing the book. Giving both people identical controls did not necessarily respect either intention.

## Begin with the decision people want to share

The first question should have been what contribution meant to the group. Was an uploaded image a suggestion, a replacement instruction or an approved page? Did a caption express one person's recollection or the wording everyone wanted printed? Who could decide that discussion had ended? These questions were already present in the activity, whether the interface acknowledged them or not. Our universal editor did not remove authority; it made authority harder to see.

I initially preferred the universal version because it seemed less restrictive. That was a product judgement I needed to revise. A restriction can be unhelpful when it prevents a person from doing what they understand themselves to be doing. A clear boundary can also protect that understanding. Someone who wants to offer material may appreciate knowing that an editor will review it before it changes the finished book. The difference depends on the task and relationship, not on a general belief that more controls always mean more empowerment.

The case for one mode remained reasonable. Multiple modes add explanation, design and testing work. They can also create uncertainty when a group chooses a mode without understanding it. We did not want to turn a personal project into a permissions workshop. The alternative therefore had to earn its additional complexity by making a real decision clearer, rather than exposing every internal distinction the engineering system was capable of representing.

Elena's research helped us describe two ordinary ways to work. In one, contributors supplied images and suggestions while an appointed editor approved the final sequence. In the other, the group deliberately chose shared editing. Those descriptions focused on what people could expect from each other. They did not require a customer to learn an internal hierarchy of access levels. The implementation still needed a rigorous account of permissions, but the product explanation began with the human activity those permissions served.

## Make authority understandable at the moment it matters

Knowing the selected mode at the beginning is useful, but the meaning of a particular action also needs to remain clear. A contributor should understand whether an image has been offered, accepted or placed in the final book. An editor should know whether another person is still suggesting changes. The buyer should not confuse the ability to place an order with evidence that everyone involved has approved the contents. These are related states, but combining them into one optimistic completion label would hide the disagreement we were trying to make manageable.

Our programme funded ₹61 lakh of development for the two modes and their explanations. Engineering colleagues owned implementation and review of the permissions. Product and research colleagues examined whether the language and task supported the intended understanding. That separation mattered because a technically correct control can still be misunderstood, while a reassuring label cannot repair a permission that behaves differently. The service needed both forms of work before it could make a credible promise about collaboration.

We also accepted that some groups would change their minds about how they wanted to work. That does not mean a product should let every consequential state change occur invisibly. The design discussion needed to consider what participants would be told, what existing contributions meant and who could authorise a change. Those questions should be addressed proportionately within the actual service rather than answered through a broad slogan about flexibility. A useful product makes important transitions understandable, including the point at which work is considered ready for production.

There is an organisational lesson here as well. Product teams can mistake a familiar internal collaboration pattern for a universal customer preference. We are accustomed to shared documents, frequent revisions and colleagues who know the software. A family making a keepsake may have different expectations, different levels of participation and different ideas about who is responsible for finishing. Research should make those differences visible before the team's own working habits become an unstated requirement of the product.

## Leave unfinished work in the account

In a later pilot with fifty-two groups, thirty-nine completed a book during the observation period and thirteen remained unfinished. We retained all thirteen in the account. An unfinished project might still be active, awaiting an image or paused for reasons unrelated to the editor. Calling each one an abandonment would have converted an observation into an unsupported explanation. Equally, excluding them would have made the completion story appear more settled than the evidence allowed.

The pilot did not establish a precise causal increase in completion from the two modes. It was a later group using a revised proposition, not a basis for every comparison we might like to make. Its useful contribution was an account of how the design worked in those projects and which questions remained. The ₹61 lakh development expense should therefore be discussed as the cost of the programme, not paired with an invented return that the observation had never measured.

For a board reviewing a collaborative product, I would ask whose authority is being represented at each consequential step. Who can contribute, who can approve and who carries the commercial commitment? Does management know where those roles differ, and can it explain how the service communicates the difference? Directors need not choose the wording on every button. They can still examine whether the company has understood the people whose intentions it is turning into a product and the obligations created by that transformation.

I would now start a collaboration proposal with a small set of real decisions rather than a list of shared features. The finished object should carry the choices the group intended to make, with disagreement and unfinished work handled openly along the way. Equal participation may sometimes mean equal editing rights. In another group it may mean being able to contribute confidently while someone else takes responsibility for completion. A thoughtful product can support both without pretending that the same controls always express the same kind of trust.