Crealead — a cooperative portal: design and prototype

Crealead — co-entrepreneurs’ portal: design and prototype

An entrepreneurs’ cooperative. An engagement to design its internal portal. The deliverable is a navigable prototype and a visual language, intended to be tested with real members before any development. No application deployed, no code delivered — and that is precisely the point of the engagement.

Sector: business services
Role: upstream design, prototype and visual language
Status: engagement completed, no code delivered

The context

An entrepreneurs’ cooperative brings together freelancers who share a legal structure and a set of services. Its internal portal has to hold together things that are not alike: tools, documents, a collective life, and people who do not know each other but would gain from doing so.

The difficulty is not drawing screens. It is deciding what the portal is: a document intranet with a directory added, or a place where people find one another and the documents sit alongside. Both answers produce the same feature list and two different products.

That is why this engagement stops before development, and why it is not a budget version of the real work. In a mockup, a block moves. Once developed, it has to be undone — and undoing always costs more than moving. An architect who starts by writing code forbids themselves from changing their mind, at the precise moment when changing your mind is still free.

The scope, stated precisely

The engagement deliberately stops before development. What it produces — a structure settled in front of real members — is what costs the most to correct afterwards.

One point that belongs to the reader rather than to me: I am myself a co-entrepreneur of this cooperative. Running its digital group and having designed its portal are two different things; the first belongs to my career, the second is this page.

The decisions

Make the directory a map, and the map the home page.

An alphabetical directory answers the question “where is this person’s file”. It does not answer the one members actually ask: who, around me, does something that concerns me.

The structure chosen therefore places the map of members at the entrance, and the documents alongside. This is not an aesthetic choice: it decides what the portal encourages. A home page listing files produces a tool you open when you need something; a page showing people produces a place you spend time in.

Settle it in front of real members, not in front of a committee.

The prototype is navigable. It does not illustrate the structure, it makes you experience it: you click, you get lost, and you discover the precise place where you got lost.

It is the only way I know of separating two structures equally defensible on paper. A committee decides on arguments; a member looking for something decides on what they find.

Deliver a visual language rather than finished screens.

Finished screens go out of date with the first unplanned feature, and the team that develops will have to invent the rest without knowing whether it is staying coherent.

A language — the components, their states, what they mean and when they are used — carries on. It costs more to produce and it outlives the engagement, which is exactly the criterion.