Role lens UIs (HCI Nerdz): “I want to…​” without hidden role assumptions

The problem: role is encoded differently everywhere

In SaaS products, “role” often shows up as scattered conditions:

  • wording changes across screens (or “mysteriously” doesn’t)

  • fields appear/disappear based on who clicked what first

  • secret-handling language differs by route, not by intent

The user experiences this as “the UI is amnesic”: the product seems to forget why it is acting the way it is acting.

The metaphor: Role lens + goal lens

Role lens + goal lens separates meaning from activation:

  • Role lens chooses which meaning is safe/expected for “who you are”. It governs labels, field affordances, and the user-facing language around secrets.

  • Goal lens answers “I want to…​” and filters what the UI should activate right now. It governs which elements are shown, which server actions are safe, and which workflow modules are enabled.

If you keep role-safe meaning and goal activation explicit, the UI can explain itself instead of branching silently.

Before and after role encoding
Role and goal routing into a single activated bundle

The UI: interactive mockup

The role lens UI is intentionally small:

  1. pick a role lens

  2. pick “I want to…​” (the goal lens)

  3. render the activated bundle (elements + functions + features)

Role lens user interface mockup

Demo

Try the interactive mockup here:

Open the Role Lens demo.

In the demo you’ll switch:

  • Role lens: Fan vs Host vs Developer

  • Goal lens (“I want to…​”): what you’re trying to accomplish next

…and watch the activated bundle change.

Design principle

Don’t encode role as a layout category like “OAuth section” or “API keys section.” Instead:

  1. keep role-safe meaning explicit

  2. activate exactly one role-safe bundle based on the goal

  3. let the whole UI subscribe to that bundle