Role-Specific Workflows Are More Than Different Dashboards

Giving each user role a different dashboard is a presentation decision. A role-specific workflow goes further: it defines what each participant is responsible for, which records they may act on, and what their actions mean to the rest of the system.

I saw this clearly while working with one other team member on an athlete discovery and scouting platform.

The platform involved three broad participants: athletes, scouts, and administrators. They used the same underlying product, but they did not simply need different menu items.

Athletes create evidence

An athlete builds a structured profile containing identity information, playing history, achievements, statistics, and video. Their workflow is about presenting accurate evidence and controlling whether the profile is complete enough to be discovered.

The interface must support creation and organization, including interactions that work with both mouse and touch. However, convenience cannot remove validation. A rearranged or newly uploaded item still needs to belong to the correct athlete and remain in a valid state.

Scouts evaluate and organize

A scout approaches the same data from a different direction. Their workflow is discovery and evaluation: search or filter athletes, inspect profiles and video, save candidates to a watchlist, and record an assessment.

A scout’s saved list or rating is not part of the athlete’s self-authored profile. It belongs to the scout’s evaluation context and may need different visibility. Modelling that distinction prevents private assessment data from accidentally becoming public athlete data.

Administrators establish trust boundaries

Administrators are responsible for platform-level controls such as reviewing media and verifying scout access. Those actions affect trust in the marketplace. They should not be treated as ordinary content editing.

Verification needs an explicit state, responsible actor, and rules about what a verified user may do. Media review also requires clear outcomes rather than a single unrestricted “admin can edit everything” shortcut.

Shared objects, different permissions

The athlete profile is a shared object, but access depends on both role and relationship. An athlete may edit their own profile. A scout may view discoverable profiles and create private evaluations. An administrator may review selected content without owning the athlete’s identity.

This is why authorization cannot be reduced to three role names. The system must also consider ownership, verification state, publication state, and the specific action being attempted.

Design around responsibility

A useful way to model a multi-sided platform is to ask four questions for every important action:

1. Who initiates it?
2. Which record and relationship authorize it?
3. What state change or evidence does it create?
4. Who can see or reverse the result?

Those answers shape the data model and workflow, not only the screen layout.

My current lesson is that role-specific design starts with responsibility. Different dashboards may make the distinction visible, but the architecture must enforce it beneath the interface.

Related work: Athlete Discovery & Scouting Platform.