Research Team Collaboration: Workspaces, Roles and Who Can See What

A Koji workspace has exactly three roles - owner, admin, and member - and every study inside it is either visible to the whole workspace or restricted to named people. Those two settings do almost all the work of research collaboration. Get them right and your team reuses research; get them wrong and people either cannot find prior work or can see things they should not.

The single most useful thing to fix first is ownership, because that is where research repositories measurably fail.

Why ownership is the failure mode

In Why Research Repositories Fail and How to Get Them Right (Maria Rosala, Nielsen Norman Group, 26 July 2024), the author surveyed over 400 UX and ResearchOps professionals. Two findings stand out.

The first is that ownership is frequently absent altogether: "29% of our respondents reported that their repository had no owner." The second is how rarely ownership is anyone's actual job - only "8% of our respondents had a ResearchOps practitioner owning the repository."

The consequences show up in adoption. Rosala reports "almost a fifth (19%) of our respondents felt that their research repository had poor adoption", with only "9% reporting mature and thriving repositories."

Read those together and the diagnosis is not a tooling problem. A repository with no owner has nobody deciding what belongs in it, nobody enforcing a naming convention, and nobody to ask when a study cannot be found. The fix begins with making ownership an explicit, enforced property of the workspace rather than a convention someone is supposed to remember.

That is precisely what a role model gives you.

The three workspace roles

Owner

The owner is the top of the workspace. Ownership is the role that controls billing and the workspace itself, and it is deliberately the hardest role to hand out - more on that below. Every workspace should have an owner who knows they are the owner.

Admin

Admins run the workspace day to day: managing people, configuring defaults, and administering studies. This is the right role for a research lead or ResearchOps practitioner - the person Rosala's data suggests is usually missing.

Member

Members do research. This is the correct default for the large majority of a team, including engineers and designers who need to read findings and run their own studies without administering anyone else.

There is no viewer role. If your instinct is to give a stakeholder read-only access to everything, the mechanism you actually want is study visibility, covered below.

Invitations: what you can and cannot grant

This is the detail that surprises people, and it is worth knowing before you plan a migration.

You can invite someone as an admin or as a member. You cannot invite someone as an owner. Ownership is not a thing you hand out in an invitation email - it is a property of the workspace that has to be transferred deliberately.

Why the restriction is the right default

An invitation is a link sent to an email address. If ownership were grantable by invitation, the highest-privilege role in your workspace would be reachable by whoever controls an inbox. Separating join the workspace from take over the workspace is a straightforward application of least privilege.

What else an invitation carries

Invitations are scoped and time-bound rather than open-ended. Each one is issued to a specific email address, moves through a defined lifecycle of pending, accepted, revoked, or expired, and can place the new person into member groups at the moment they join, so access does not depend on someone remembering a follow-up step. Invitations that are never accepted expire rather than remaining valid indefinitely.

Study visibility: workspace or restricted

Separately from roles, each study carries a visibility setting with two values.

Workspace visibility means everyone in the workspace can see the study. This should be your default, and it is the setting that makes research reusable. The duplication problem Rosala describes - teams rerunning studies whose findings already exist - is largely a visibility problem wearing a discovery costume.

Restricted visibility limits the study to named people. The workspace also carries a default visibility setting, so you can decide once whether new studies start open or closed rather than relying on per-study discipline.

When restricted is genuinely the right call

Restrict a study when the participants are identifiable and the topic is sensitive - employee research about managers, exit interviews, anything touching health or finances. Restrict it when a commercial embargo genuinely applies, such as pre-announcement pricing work.

When restricted is a mistake

Do not restrict a study because it is unfinished, or because the findings are unflattering, or out of vague caution. Default-closed research is the main reason repositories go stale: people stop looking in a place that has usually told them no.

If your concern is that raw transcripts contain personal data but the findings do not, the answer is not blanket restriction - it is anonymising the interview data so the study can safely stay open.

Member groups

Roles answer what can this person do. Member groups answer which slice of the work is this person part of, which is what you need once a workspace outgrows a single team. A group has a name and description, and within a group a person is either a manager or a member.

Groups are how you model a research guild, a product squad, or a regional team without inventing new permission levels. Note the group role is separate from the workspace role: being a group manager is about that group, not about the workspace.

Personal and shared workspaces

A workspace is either personal or shared. Personal is the single-user case - the solo researcher or founder doing their own studies. Shared is the collaborative case with roles, invitations, and groups.

The practical advice is to move to a shared workspace earlier than feels necessary. Research done in a personal workspace is invisible to everyone else by construction, which is the most complete form of the discoverability failure above.

The audit trail

Workspace activity is recorded: who acted, what action was taken, who it affected, and when. This matters for two quite different reasons.

The first is security review. Enterprise buyers ask who can see interview data and how you would know if that changed - see Enterprise Security for AI Customer Research Platforms.

The second is ordinary operational sanity. When a study's visibility changes or someone loses access, the useful question is not who did this in an accusatory sense but what changed and when, so you can put it back.

How Koji handles this

• Koji enforces exactly three workspace roles - owner, admin, and member - so permissions cannot drift into a bespoke scheme nobody understands.
• Invitations can grant admin or member only, never owner, keeping the highest privilege out of email.
• Each study is workspace-visible or restricted, and the workspace carries a default so the safe choice is made once rather than per study.
• Member groups let a large workspace model squads and guilds without adding permission levels.
• Workspace actions are written to an audit trail, so access changes are reconstructable rather than folklore.
• Because Koji runs the interviews as well as storing them, a study that is visible is immediately useful - the transcript, the structured answers across all six question types - open_ended, scale, single_choice, multiple_choice, ranking, and yes_no - and the report all travel together rather than living in three tools.

Common mistakes

Making everyone an admin

The most common one, usually done to unblock somebody quickly. It defeats the point of having roles and makes the audit trail much harder to reason about. Member is the right default in Koji; promote deliberately.

Leaving ownership implicit

If nobody can name the owner of your workspace, you are in the 29% Rosala measured. Name an owner in your Koji workspace, tell them, and make sure an admin exists who is not the same person.

Defaulting studies to restricted

This looks prudent and quietly causes the duplication it was meant to prevent. Default to workspace visibility and restrict the specific studies that genuinely need it.

Treating visibility as a substitute for data handling

Restricting a study controls who can open it. It does not minimise what was collected or set how long it is kept. Those are separate obligations - see Research Data Retention and Deletion.

Frequently asked questions

What are the three workspace roles in Koji?

Owner, admin, and member. The owner sits at the top of the workspace and controls billing and the workspace itself, admins manage people and studies day to day, and members do research. There is no separate viewer role - use study visibility instead if you want to limit what someone can open.

Can I invite someone directly as an owner?

No. Invitations can grant admin or member only. Ownership has to be transferred deliberately rather than handed out in an invitation, which keeps the highest-privilege role in your workspace from being reachable by whoever controls an email inbox.

What is the difference between workspace and restricted visibility?

A workspace-visible study can be opened by everyone in the workspace, which is what makes prior research reusable. A restricted study is limited to named people. Your workspace also has a default visibility setting so new studies start the way you intend.

Who can see interview transcripts and personal data?

Anyone who can open the study. That is why visibility, not role, is the control to reach for when a study contains identifiable or sensitive material - and why anonymising the data is often the better answer, since it lets the findings stay discoverable without exposing participants.

Do member groups replace roles?

No, they work alongside them. Roles decide what a person can do in the workspace; groups decide which slice of the work they belong to, such as a squad or a regional team. Within a group a person is either a manager or a member, and that is independent of their workspace role.

How do I prove who changed what?

Workspace activity is recorded with the actor, the action, the affected person, and a timestamp. This is what you show during a vendor security review, and it is also how you work out what to put back when someone unexpectedly loses access.

Related Resources

• Structured Questions Guide - the six question types every study in your workspace is built from
• Enterprise Security for AI Customer Research Platforms - SOC 2, SSO and what vendor reviewers ask about access
• Anonymizing Customer Interview Data - how to keep a study open without exposing participants
• Research Data Retention and Deletion - how long to keep interview data
• UX Research Team Structure - centralised, embedded and hub-and-spoke models
• Managing Research Participants - the operational view of a running study