Showing posts with label user. Show all posts
Showing posts with label user. Show all posts

Journey Mapping 101

Mike's Notes

I'm wondering whether Journey Maps could be added to Pipi.

  • To better understand the needs of the different users of Pipi visually
  • As a tool for customers.
I first used Journey Mapping a few months ago while testing Krobar.ai, an excellent simulation platform from Kromatic.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > NNg Newsletter
  • Home > Handbook > 

Last Updated

18/01/2026

Journey Mapping 101

By: Sarah Gibbons
NN Group: 09/12/2018

Vice President of Nielsen Norman Group. She works at the intersection of research, strategy, and design.

Summary

A journey map is a visualization of the process that a person goes through in order to accomplish a goal.

Journey maps are a common UX tool. They come in all shapes, sizes, and formats. Depending on the context, they can be used in a variety of ways. This article covers the basics: what a journey map is (and is not), related terminology, common variations, and how we can use journey maps.

In This Article

  • Definition of a Journey Map
  • Key Components of a Journey Map
  • Journey-Map Variations
  • Why Use Journey Maps
  • Conclusion

Definition of a Journey Map

Definition: A journey map is a visualization of the process that a person goes through in order to accomplish a goal.

In its most basic form, journey mapping starts by compiling a series of user actions into a timeline. Next, the timeline is fleshed out with user thoughts and emotions in order to create a narrative. This narrative is condensed and polished, ultimately leading to a visualization.

Most journey maps follow a similar format: at the top, a specific user, a specific scenario, and corresponding expectations or goals in the middle, high-level phases that are comprised of user actions, thoughts, and emotions;  at the bottom, the takeaways: opportunities, insights, and internal ownership.

The terms ‘user journey map’ and ‘customer journey map’ can be used interchangeably. Both reference a visualization of a person using your product or service.

While the argument can be made that the term ‘customer’ does a disservice to the method (because, especially for certain business-to-business products, not all of end users are technically customers, i.e., product buyers), alignment on what you call the map is far less important than alignment on the content within the map.

Key Components of a Journey Map

Journey maps come in all shapes and sizes. Regardless of how they look, journey maps have the following 5 key elements in common:

  1. Actor
  2. Scenario + Expectations
  3. Journey Phases
  4. Actions, Mindsets, and Emotions
  5. Opportunities

Actor

The actor is the persona or user who experiences the journey. The actor is who the journey map is about — a point of view. Actors usually align with personas and their actions in the map are rooted in data.

Provide one point of view per map in order to build a strong, clear narrative. For example, a university might choose either a student or a faculty member as actor — each would result in different journeys. (To capture both viewpoints, the university will need to build two separate maps, one for each of the two user types.)

Scenario + Expectations

The scenario describes the situation that the journey map addresses and is associated with an actor’s goal or need and specific expectations. For example, one scenario could be switching mobile plans to save money, and expectations for it include to easily find all the information needed to make a decision.

Scenarios can be real (for existing products and services) or anticipated — for products that are yet in the design stage.

Journey maps are best for scenarios that involve a sequence of events (such as shopping or taking a trip), describe a process (thus involve a set of transitions over time), or might involve multiple channels.

Journey Phases

Journey phases are the different high-level stages in the journey. They provide organization for the rest of the information in the journey map (actions, thoughts, and emotions). The stages will vary from scenario to scenario; each organization will usually have data to help it determine what these phases are for a given scenario.

Here are some examples:

  • For an ecommerce scenario (like buying Bluetooth speakers), the stages can be discover, try, buy, use, seek support.
  • For big (or luxury) purchases (like buying a car), the stages can be engagement, education, research, evaluation, justification.
  • For a business-to-business scenario (like rolling out an internal tool), the stages could be purchase, adoption, retention, expansion, advocacy.

Actions, Mindsets, and Emotions

These are behaviors, thoughts, and feelings the actor has throughout the journey and that are mapped within each of the journey phases.

Actions are the actual behaviors and steps taken by users. This component is not meant to be a granular step-by-step log of every discrete interaction. Rather, it is a narrative of the steps the actor takes during that phase.

Mindsets correspond to users’ thoughts, questions, motivations, and information needs at different stages in the journey. Ideally, these are customer verbatims from research.

Emotions are plotted as single line across the journey phases, literally signaling the emotional “ups” and “downs” of the experience. Think of this line as a contextual layer of emotion that tells us where the user is delighted versus frustrated.

Opportunities

Opportunities (along with additional context such as ownership and metrics) are insights gained from mapping; they speak to how the user experience can be optimized. Insights and opportunities help the team draw knowledge from the map:

  • What needs to be done with this knowledge?
  • Who owns what change?
  • Where are the biggest opportunities?
  • How are we going to measure improvements we implement?

An example of a simplistic, high-level customer-journey map depicting how the persona “Jumping Jamie” switches her mobile plan. While all comprehensive journey maps should include key components, what the map chooses to prioritize can (and should) depend on the goal of the journey-mapping initiative. (For your convenience, we provide a journey-map template that you can use.)

Journey-Map Variations

There are several concepts closely related and thus easily confused with journey maps.

It is important to note that this section is only meant to help your personal understanding and clarification of these terms. It is not advised to debate or attempt to shift a whole organization’s language to abide by the definitions stated here. Instead, use these definitions to guide you towards aspects of another method that your team has not previously considered.

Journey Map vs. Experience Map

Think of an experience map as a parent to a journey map. A journey map has a specific actor (a singular customer or user of a product) and specific scenario (of a product or service), while an experience map is broader on both accounts — a generic human undergoing a general human experience.

The experience map is agnostic of a specific business or product. It’s used for understanding a general human behavior; in contrast, a customer journey map is specific and focused on a particular business or product.

For example, imagine the world before the ridesharing market existed (Uber, Lyft, Bird, or Limebike, to name a few). If we were to create an experience map of how a person gets from one place to another, the map would likely include walking, biking, driving, riding with a friend, public transportation, or calling a taxi. Using that experience map we could then isolate pain points: unknown fares, bad weather, unpredictable timing, paying in cash, and so on. Using these pain points, we would then create a future journey map for specific product: how does a particular type of user call a car using the Lyft app?

Journey Map vs. Service Blueprint

If journey maps are the children to experience maps, then service blueprints are the grandchildren. They visualize the relationships between different service components (such as people or processes) at various touchpoints in a specific customer journey.

Think of service blueprints as a part two to customer journey maps. They are extensions of journey maps, but instead of being focused on the user (and taking the user’s viewpoint), they are focused on the business (and take its perspective).

For the Lyft scenario above, we would take the journey map and expand it with what Lyft does internally to support that customer journey. The blueprint could include matching the user to a driver, contacting the driver, calculating fares, and so on.

Journey Map vs. User Story Map

User stories are used in Agile to plan features or functionalities. Each feature is condensed down to a deliberately brief description from a user’s point of view; the description focuses on what the user wants to do, and how that feature will help. The typical format of a user story is a single sentence: “As a [type of user], I want to [goal], so that [benefit].” For example, “As a checking account holder, I want to deposit checks with my mobile device, so that I don’t have to go to the bank.”

A user story map is a visual version of a user story. For example, take the user story above (“As a checking account holder, I want to deposit checks with my mobile device, so that I don’t have to go to the bank.”) and imagine writing out the different steps that the team plans for the user to take when using that functionality. These steps could be: logging in, beginning deposit, taking picture of check, and entering transaction details. For each step, we can document required features: enabling camera access, scanning check and auto filling numbers, and authorizing signature. In a user story map, these features are written on sticky notes, then arranged based on the product release that each functionality will be added to.

While, at a glance, a user story map may look like a journey map, journey maps are meant for discovery and understanding (think big picture), while user story maps are for planning and implementation (think little picture).

Although a journey map and user story map may contain some of the same pieces, they are used at different points of the process. For example, imagine our journey map for Lyft indicated that a pain point appeared when the user was in a large group. To address it, the team may introduce a multicar-call option. We could create a user story map to break this feature (multicar call) into smaller pieces, so a product-development team could plan release cycles and corresponding tasks.

Why Use Journey Maps

The benefits of journey maps (and most other UX mappings) are two-fold. First, the process of creating a map forces conversation and an aligned mental model for the whole team. Fragmented understanding is a widespread problem in organizations because success metrics are siloed; it is no one’s responsibility to look at the entire experience from the user’s standpoint. This shared vision is a critical goal of journey mapping, because, without it, agreement on how to improve customer experience would never take place.

Second, the shared artifact resulting from the mapping can be used to communicate an understanding of your user or service to all involved. Journey maps are effective mechanisms for conveying information in a way that is memorable, concise, and that creates a shared vision. The maps can also become the basis for decision making as the team moves forward.

Conclusion

Journey mapping is a process that provides a holistic view of the customer experience by uncovering moments of both frustration and delight throughout a series of interactions. Done successfully, it reveals opportunities to address customers’ pain points, alleviate fragmentation, and, ultimately, create a better experience for your users.

Additional articles are available, discussing: 

  • When to create customer journey maps
  • The 5-step process
  • Journey mapping in real life

By , No comments:
Tags ,

Developer access to Pipi, is coming

Mike's Notes

The data is precise on this one. Unfortunately, the current developer interest in NZ and Australia is 3% and 0%, respectively. I also can't find anyone in NZ who has the slightest technical understanding of what I'm doing. But there are plenty overseas, especially in MLOps. We speak the same language, even if the architecture and algorithms are radically different. Also, top-grade mathematicians get it. Internally, Pipi 9 uses a lot of maths.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

08/12/2025

Developer access to Pipi is coming

By: Mike Peters
On a Sandy Beach: 02/12/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The problem

To launch Pipi 9 with limited resources in 2026, the effort needs to be highly focused on developers who build large enterprise systems and have experienced failure, cost overruns, and staggering complexity. This is for them.

Waste

The staggering annual global cost of IT failures on big projects is around $US 3 trillion. How many schools or knee replacements would that be?

  • 15% succeed
  • 25% makes no difference
  • 60% fail

Web traffic stats

The steadily growing web traffic statistics of public interest in Pipi 9 are becoming very clear.

Since early 2019, the total traffic stats by country are;

  • China 19%
  • Singapore 16%
  • United States 15%
  • Hong Kong 11%
  • Brazil 10%
  • TOTAL 71%

Developer Accounts

The initial paid Developer Accounts will be restricted to experienced DevOps teams with great internal culture in those five countries. That also affects the language, currency, hours of support availability, etc. Later, as interest and resources grow, that list of countries can be expanded.

Personal Accounts

The free Personal Accounts will initially use an English interface and will not be restricted by country of residence. They will get community support.

Enterprise Accounts

The initial paid Enterprise Accounts will be supported by their associated Developer Accounts, who can charge them whatever they want for that service. They will initially use an English interface and will not be restricted by country of residence. Developer Accounts will be able to translate UI and documentation into any language and writing system.

Pipi 9 is in hiding

This engineering blog and the many other Ajabbi documentation websites are deliberately hidden from search engines. People are visiting because they are curious, as I write notes to myself and build, learning as I go. It is not easy to find the technical documentation unless you are really interested, clever and very determined. That has helped me find some early, keen technical fans who provide testing and feedback. It has also protected me from being overwhelmed by enquiries.

Communication constraints

I am a very slow writer, using assistive technology, have hearing problems and prefer video chats with people who speak good, clear English. I don't speak any other language apart from tiny bits of Maori, French and Spanish.

SEO and GEO

The SEO/GEO settings will be fixed when

  • Pipi 9 matures and becomes ready for public use
  • Community support is in place
  • Bugs fixed
  • Enough self-help documentation to help people get started.

Developer Account waitlist

There will be a signup queue to control demand, so scaling is steady with a positive resource feedback loop to solve the chicken-and-egg problem. The small queue is growing now. I will pick the best candidates with the highest chance of success. They will gain a first-mover advantage in building large, custom enterprise systems faster and at a much lower cost. The first ones will get free unlimited support. 

Relying on word-of-mouth recommendations.

There will be no marketing or sales, just good, clear documentation, live demos, and regular bookable office hours (NZ daytime) for having a chat.

Inflexion point

In the future, as workspaces mature and Pipi 10 becomes even easier to work with, resource constraints will disappear, teams will grow, and an inflexion point will be reached. Anyone will then be able to sign up.

By , No comments:
Tags , , ,

Your Users Aren’t Lazy—They’re Managing Change Overload

Mike's Notes

More thoughtful words of wisdom from IT Revolution.

Resources

References

  • Progressive Delivery: Build The Right Thing For The Right People At The Right Time by James Governor, Kim Harrison, Heidi Waterhouse, and Adam Zimman (IT Revolution Press, November 2025).

Repository

  • Home > Ajabbi Research > Library > Subscriptions > IT Revolution
  • Home > Handbook > 

Last Updated

12/10/2025

Your Users Aren’t Lazy—They’re Managing Change Overload

By: Leah Brown
IT Revolution: 02/10/2025

Managing Editor at IT Revolution working on publishing books and guidance papers for the modern business leader. I also oversee the production of the IT Revolution blog, combining the best of responsible, human-centered content with the assistance of AI tools.

Picture this: A seasoned medical coder sits down at her workstation every morning and flies through insurance claims at lightning speed. Her fingers dance across function keys and the ten-key pad without her eyes ever leaving the screen. She processes more claims in an hour than most people could handle in a day.

Then your team delivers a “user-friendly” modernization of her software. Suddenly, she needs a mouse. The keyboard shortcuts she’s memorized over decades no longer work. Tasks that took seconds now require multiple clicks through dropdown menus. Her productivity plummets.

Is she being resistant to change? Lazy? Unwilling to learn?

None of the above. She’s managing change overload in the only way that makes sense: by protecting the workflows that keep her livelihood intact.

This scenario, shared by coauthor Heidi Waterhouse in the upcoming book Progressive Delivery, illustrates a fundamental misunderstanding that’s costing organizations millions in failed software rollouts, user frustration, and abandoned features.

The Change Paradox

Here’s what seems contradictory but is actually perfectly logical: the same person who eagerly upgrades their iPhone every year might resist a minor update to their work software. The same developer who constantly experiments with new programming languages might refuse to adopt your team’s new deployment tool.

This isn’t hypocrisy—it’s smart change management.

People have a finite capacity for absorbing change. We instinctively protect our most critical workflows while remaining open to improvement in areas where failure isn’t catastrophic. Your iPhone upgrade can be undone or worked around. Your work software, which determines whether you can pay your mortgage, demands much more careful consideration.

Beyond Stakeholders: Understanding Your Full Constituency

Most organizations think about their users as “stakeholders”—people who have a financial or organizational interest in the product’s success. But Progressive Delivery requires thinking about “constituents”—everyone who is actually affected by your software, whether they appear on your org chart or not.

Consider medical records software. The obvious stakeholders are:

  • Doctors who input patient data.
  • Hospital administrators who purchase the software.
  • IT teams who maintain the systems.
  • Your development team who builds features.

But the full constituency includes:

  • Nurses who need to access information during emergencies.
  • Patients who use portals to view their own data.
  • Family members helping elderly relatives navigate health information.
  • Regulatory bodies ensuring privacy compliance.
  • Insurance companies processing claims.
  • Medical billers like our friend above.

Each constituent has different change tolerance levels, different technical sophistication, and different stakes in maintaining stability versus embracing innovation.

The Three Types of Change Capacity

Not all users approach change the same way. Understanding these differences is crucial for delivering software that actually gets adopted:

  • The Builder Mindset Some users see software as LEGO blocks—they want to understand how things work and customize their experience. These are your early adopters who read release notes, experiment with beta features, and provide detailed feedback. They have high change tolerance because they enjoy the process of discovery and optimization. They’re willing to invest time learning new workflows because they see it as creative problem-solving.
  • The Tool Mindset Most users see software as a hammer—they want it to reliably perform specific tasks without requiring constant attention. They’ve developed efficient workflows around current functionality and view changes through the lens of “will this help me get my job done better?” They have moderate change tolerance when improvements clearly align with their goals, but they resist changes that disrupt established patterns without obvious benefit.
  • The Survival Mindset Some users interact with software in high-stakes environments where mistakes have serious consequences. Medical professionals, financial traders, air traffic controllers—these users have optimized their workflows for safety and reliability above all else. They have very low change tolerance because their primary concern isn’t efficiency improvement—it’s avoiding catastrophic failure.

The Cost of Misreading Your Constituency

When you misunderstand your users’ change capacity, you create what Progressive Delivery calls “technological jerk“—the jarring experience of change happening too fast for people to absorb.

Slack’s 2019 redesign perfectly illustrates this mismatch. Slack’s design team saw an opportunity to create a more modern, streamlined interface. They were thinking like builders—excited about cleaner visual hierarchy and improved information architecture. But most Slack users weren’t builders—they were people managing dozens of conversations across multiple workspaces while trying to get their actual jobs done. The redesign disrupted muscle memory, changed keyboard shortcuts, and reorganized familiar layouts. What felt like an improvement to the design team felt like chaos to users trying to maintain productivity.

Sonos’s 2024 app disaster represents an even more dramatic failure. The company released an app update that broke core functionality like sleep timers and queue management. Users weren’t just annoyed—they were unable to perform basic tasks with expensive hardware they’d already purchased. CEO Patrick Spence was forced to resign in January 2025.

In both cases, the companies built better software from a technical perspective but failed to consider how changes would land with people who depended on existing workflows.

The Adobe Alternative: Progressive Control

Adobe provides a masterclass in respecting user change capacity while still driving innovation. When they integrated AI into their Creative Cloud suite, they could have simply pushed the latest models to everyone simultaneously. Instead, they implemented what Progressive Delivery calls “radical delegation.”

Users can choose which AI model version to use for different projects. Someone working on a long-term brand campaign can maintain consistency with Firefly v1, while someone experimenting with new creative techniques can opt into Firefly v3. The same user might make different choices for different contexts.

This isn’t just about offering a “classic mode” checkbox. Adobe created granular controls that let users manage their own change absorption rate based on their specific needs and risk tolerance.

Three Strategies for Respecting Change Capacity

  1. Delegate Control to the Point of Impact: Instead of deciding when users should adopt new features, give them the tools to make that decision themselves. Microsoft’s “Try the new Outlook” toggle lets users test the redesigned experience and revert if needed. Google Workspace offers separate release tracks for organizations with different change tolerance levels. The key is making this choice meaningful—not just a temporary beta flag that eventually disappears, but ongoing control over their experience.
  2. Design for Multiple Speeds Simultaneously: Your power users and cautious users don’t need to move at the same pace. GitHub ships hundreds of small changes that are mostly invisible to casual users but provide meaningful improvements for developers who spend all day in the platform. Meanwhile, major feature releases are carefully communicated and gradually rolled out. This allows your constituency to self-select into the change pace that matches their capacity and context.
  3. Build Reversible Experiences: Make it safe to experiment by making it easy to step back. This isn’t just about technical rollback capabilities—it’s about user confidence. When people trust they can explore new functionality without getting trapped in unfamiliar territory, they’re more willing to try changes. Netflix’s interface experiments are a good example. They test thousands of variations, but users never feel stuck with a version they dislike because the changes are either subtle or easily reversible.

The Empathy Advantage

Organizations that successfully implement Progressive Delivery share a crucial insight: user “resistance” is usually valuable information about change capacity, not character flaws to overcome.

When users complain about the pace of updates, they’re telling you about their bandwidth for absorption. When they create workarounds to avoid new features, they’re showing you that your timing doesn’t match their readiness. When they stick with “legacy” workflows, they’re protecting something valuable that you might not understand.

Instead of viewing this feedback as obstacles to overcome, Progressive Delivery treats it as essential input for delivering software that actually creates value.

The Path to Sustainable Innovation

Here’s the paradox: When you respect users’ change capacity, you can actually innovate faster. Users who trust that you won’t disrupt their critical workflows are more willing to experiment with new capabilities. Users who feel heard and respected become advocates rather than resistors.

Progressive Delivery isn’t about slowing down innovation—it’s about ensuring innovation actually reaches the people who need it, when they’re ready to receive it.

Your users aren’t lazy. They’re not change-averse. They’re not technologically backward.

They’re intelligent people managing complex workflows in environments where stability matters. They’re making rational decisions about where to invest their limited change capacity. They’re protecting their ability to be productive while remaining open to genuine improvements.

The question isn’t how to overcome user resistance. The question is how to build delivery systems that work with human change capacity rather than against it.

When you get that right, everyone wins: users get software that actually makes their lives better, and you get the sustainable adoption that drives real business value.

This post explores concepts from the upcoming book Progressive Delivery: Build The Right Thing For The Right People At The Right Time by James Governor, Kim Harrison, Heidi Waterhouse, and Adam Zimman (IT Revolution Press, November 2025).


By , No comments:
Tags , ,

User account types and workspace URLs

Mike's Notes

My notes to make explicit how workspace URLs work with different user account types. I tend to make these sorts of decisions as late as possible, when the correct choice becomes very obvious.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

08/11/2025

User account types and workspace URLs

By: Mike Peters
On a Sandy Beach: 02/10/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

My work this week has been focused on determining the naming pattern for workspace URLs. The pattern can differ by user account type.

User Account Types

  • Agent
  • Developer
  • Enterprise
  • Personal
  • Research
  • SME
  • Temp

Agent Account

  • Always in credit and paid by usage.
  • For Pipi to self-manage.
  • Utilises a swarm of Pipi hosts operating within an ecosystem.
  • i18n English-UK URLs.
  • "a" prefix.
  • Uses agent-tenanted workspaces.
  • Uses raw codename patterns in the workspace URL naming.
  • It is a digital twin.
  • Permanent.

Developer Account

  • Always in credit and paid by usage.
  • For developers to support enterprise accounts.
  • Uses a dedicated Pipi host.
  • i18n URLs available.
  • "d" prefix.
  • Uses sole-tenanted workspaces.
  • Uses selectable patterns in the workspace URL naming.
  • No digital twin. Works with customer digital twins.
  • Permanent.

Enterprise Account

  • Always in credit and paid by usage.
  • For large organisations with huge systems.
  • Uses dedicated Pipi hosts.
  • i18n URLs available.
  • "e" prefix.
  • Uses sole-tenanted workspaces.
  • Uses customised patterns in the workspace URL naming.
  • Dedicated digital twin.
  • Permanent.

Personal Account

  • Free.
  • Everyone who gets a username and password.
  • Shares a common Pipi host.
  • i18n URLs available.
  • "p" prefix.
  • Uses a multi-tenanted workspace.
  • Uses standard patterns in the workspace URL naming.
  • Shared digital twin.
  • Permanent.

Research Account

  • Always in credit and paid by usage.
  • For researchers to train Pipi.
  • Uses a dedicated Pipi host.
  • i18n URLs available.
  • "r" prefix.
  • Uses sole-tenanted workspaces.
  • Uses raw codename patterns in the workspace URL naming.
  • Dedicated digital twin.
  • Permanent.

SME Account

  • Always in credit and paid by plan.
  • For small organisations or businesses that want to use simple apps.
  • Shares a common Pipi host.
  • i18n URLs available.
  • "s" prefix.
  • Uses multi-tenanted workspaces.
  • Uses standard patterns in the workspace URL naming.
  • Shared digital twin.
  • Permanent.

Temp Account

  • Free.
  • For temporary users who need to do something without creating an account.
  • No Pipi host.
  • i18n URLs available.
  • "t" prefix.
  • Uses a multi-tenanted workspace.
  • Uses standard patterns in the workspace URL naming.
  • No digital twin.
  • Temporary.
By , No comments:
Tags , , , ,

RBAC Policies

Mike's Notes

I'm building the Policy part of RBAC

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/09/2025

RBAC Policies

By: Mike Peters
On a Sandy Beach: 10/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I'm loosely copying how Windows implements RBAC. Mainly to understand how it works.

From Windows Learn (without the pictures).

To create an access policy

  1. In Server Manager, click IPAM. The IPAM client console appears.
  2. In the navigation pane, click ACCESS CONTROL. In the lower navigation pane, right-click Access Policies, and then click Add Access Policy.
  3. The Add Access Policy dialog box opens. In User Settings, click Add.
  4. The Select User or Group dialog box opens. Click Locations.
  5. The Locations dialog box opens. Browse to the location that contains the user account, select the location, and then click OK. The Locations dialog box closes.
  6. In the Select User or Group dialog box, in Enter the object name to select, type the user account name for which you want to create an access policy. Click OK.
  7. In Add Access Policy, in User Settings, User alias now contains the user account to which the policy applies. In Access Settings, click New.
  8. In Add Access Policy, Access Settings changes to New Setting.
  9. Click Select role to expand the list of roles. Select one of the built-in roles or, if you have created new roles, select one of the roles that you created. For example, if you created the IPAMSrv role to apply to the user, click IPAMSrv.
  10. Click Add Setting.
  11. The role is added to the access policy. To create additional access policies, click Apply, and then repeat these steps for each policy that you want to create. If you do not want to create additional policies, click OK.
  12. In the IPAM client console display pane, verify that the new access policy is created.

By , No comments:
Tags , , , ,

Role-Based Access Control (RBAC)

Mike's Notes

I'm revisiting the role-based access control (RBAC) in Pipi.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

13/09/2025

Role-Based Access Control (RBAC)

By: Mike Peters
On a Sandy Beach: 08/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Pipi 4

Pipi utilised a simple role-based access control (RBAC) system. It enforced a change of passwords for both admins and users. The old data model was similar to the one depicted in this diagram.

Pipi 9

Using RBAC to administer accounts for users must scale from very simple to large. Something much more robust is required.

Requirements

Entities;

  • Users
  • Policy
  • Roles
  • Permissions
  • Groups
  • Objects
  • Sessions
  • Join tables

Roles;

  • In a hierarchy.
  • Separation of duties by allowing and denying access.
  • Fine-grained.

Uses;

  • Pipi as an ecosystem and an individual system.
  • Each account
  • Organisational structures within an account
  • Shares
  • Individual users
  • The public
The RBAC needs to be automatically logged, tested and audited.

By , No comments:
Tags , , , ,

Supporting “Power Users” Isn’t Enough: 3 Complex-App User Types

Mike's Notes

I will implement this excellent advice in future changes to the Pipi UI framework.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > The NN/g Newsletter
  • Home > Handbook > 

Last Updated

07/07/2025

Supporting “Power Users” Isn’t Enough: 3 Complex-App User Types

By: Kate Kaplan
NNGroup: 27/06/2025

Kate Kaplan is Nielsen Norman Group's Insights Architect. She specializes in the application of human-centered design and research practices to enterprise UX challenges. With over 15 years in UX, Kate has extensive experience in both conducting research and helping teams understand and apply user insights to overall business strategy.

Summary:

Complex-app users don’t always fit neatly into “novice” or “expert” labels. Designing for Legacy, Legend, and Learner users leads to more inclusive, effective systems.

When designing complex applications, practitioners often feel pressure to center efforts around “power” users: highly trained professionals with deep domain knowledge and years of experience using the software in question. While these expert users are important, focusing solely on them means overlooking other critical user types.

This tendency reflects a deeper issue: the overly simplistic assumption that complex-app users fall into one of two categories: either novices or experts. In reality, this binary framing fails to account for the users who don't fit cleanly into either category — such as long-term users who never achieved deep system mastery, or domain experts who are new to the software and still learning how to navigate complex workflows. Failing to recognize these nuances results in exclusionary design, inefficient workflows, and missed opportunities to improve user experience.

In This Article:

  • Three Complex Apps User Types
    • 1. The Legacy
    • 2. The Legend
    • 3. The Learner
  • Balancing All Three User Types

Three Complex Apps User Types

To move beyond the novice-expert binary, we need a more nuanced understanding of how people actually engage with complex applications.

Complex applications are systems designed to support specialized workflows, often involving multiple user roles, advanced configurations, and domain-specific operations. 

These tools demand higher levels of cognitive load and feature density compared to typical consumer apps, and they attract a broad range of users whose experience with the software varies widely.

When I coach people to design better complex applications, I highlight three distinct complex-app user profiles whose needs, behaviors, and limitations are often misunderstood or overlooked.

  • The Legacy: The long-term user with deep familiarity but low efficiency
  • The Legend: The power user who has achieved expert-level proficiency
  • The Learner: The domain expert who is new to the software and still building system knowledge

Each of these user types presents distinct design challenges and opportunities that are often overlooked in design decisions and roadmap planning.

1. The Legacy

A legacy user has used the software for years or even decades but hasn’t become truly efficient. Longevity has not translated into true system expertise or understanding. We often mistake legacy users for power users, assuming that frequent and long-term use equates to deep system expertise. However, many of these users continue using the system inefficiently for decades, learning and utilizing only what they need to get by, rather than the system as a whole.

Legacy users often:

  • Use rigid, familiar methods to accomplish tasks
  • Avoid customization and stick to system defaults
  • Use only a narrow slice of the application’s features
  • Develop workarounds (e.g., bookmarks, personal notes, manual processes)

How Legacy Users Are Left Behind

Legacy users are often viewed as resistant to change. The assumption is that they simply don’t want to learn new methods and fear any design modifications, optimizations, or usability improvements. But, in reality, what they often fear is loss of productivity, not change itself. 

Many of these users have adapted to suboptimal workflows over time and are wary of changes that disrupt what little efficiency they have established. 

As one complex-apps practitioner explained, this resistance often stems from deep habits and experience with the existing system:

It wasn't what they were used to. There was that resistance to change. They have great muscle memory. They have great experience. They know workarounds on how to maneuver or how to operate certain things.

These ingrained behaviors can make it difficult for legacy users to recognize inefficiencies or adapt to new workflows, even when those workflows are objectively better designed.

How to Support Legacy Users

Supporting legacy users means recognizing that familiarity doesn’t always equal mastery, and that productivity, not resistance, is often at the heart of their hesitation. The key is to introduce improvements with change-aversion in mind — in a way that feels safe, respectful of their workflows, and clearly beneficial. 

To support legacy users:

  • Avoid sudden, large-scale UI changes that disrupt learned behaviors
  • Communicate upcoming changes early and clearly
  • Provide the option to keep legacy views or workflows during transition periods
  • Offer low-risk beta environments to explore new features
  • Involve them in usability testing and rollout feedback loops
  • Emphasize feature discoverability, especially for time-saving shortcuts

2. The Legend

A legend user is a system expert who has reached a high level of efficiency and fluency within the application. They’ve mastered shortcuts, customized their workflows, and are often deeply embedded in user communities or advisory roles.

We often hear from legend users the most through channels such as forums, beta launches, and customer advisory groups. Their influence can be substantial, and their requests often reflect deep technical understanding and a desire for even greater user control and freedom.

Legends often:

  • Use keyboard shortcuts, macros, and accelerators extensively
  • Advocate for advanced features and customization
  • Desire and request greater flexibility in workflows and outputs
  • Engage heavily in feedback channels, user communities, or advisory boards

How Legend Users Are Left Behind

Legend users introduce two different but significant risks.

First, their feedback may be over-prioritized (either due to their willingness to vocalize their desires or insistence from the business that they are the most “valuable” users). While their input is valuable, over-prioritizing it can skew product decisions toward edge-case, high-effort features that don't benefit the broader user base. This risks bloated features and added complexity for everyone else.

Second, their continued usage of the system is often taken for granted by the business. It's easy to assume that because they’ve mastered the system, they’ll remain loyal. But even legends have limits. When they hit a performance ceiling — or see better, more efficient tools emerge elsewhere — they may abandon the product in search of greater speed, flexibility, or control.

One complex-app practitioner reflected on this competitive pressure from newer, more agile tools:

A lot of other technologies have been innovative and disruptive in the last 15 years. More [companies] have been able to create their own tools and software, and it's like, ‘Wow, you can really get going and do things way faster and easier [with other tools].’

If organizations assume legend users will always stay loyal, they risk overlooking the very real need to continually improve performance and usability for this group.

How to Support Legend Users

Supporting legend users means treating them not just as vocal power users, but as valuable early indicators of system limitations and opportunities. They need continued innovation to stay engaged, and product teams need to listen with discernment, balancing their input with broader user needs.

To support legend users:

  • Don’t assume loyalty; continue to innovate and optimize
  • Conduct regular competitive audits to understand what other tools offer
  • Provide advanced features without compromising core usability
  • Invite legend users into early betas or pilot programs to test high-efficiency features
  • Recognize and celebrate their contributions, but avoid letting their preferences overrule broader design priorities

3. The Learner

The learner is new to the system but not the domain. They bring deep subject-matter expertise but limited familiarity with the system’s workflows, features, and capabilities.

We often assume that learners will simply “figure it out” through training or forced repetition. But without early support, these users may never gain the confidence or fluency needed to use the system effectively. Worse, they may develop workarounds that bypass core features, or disengage entirely due to mistrust in the system.

Learners often:

  • Learn by doing, diving into the interface without any true onboarding
  • Struggle with discovering key functions or the most efficient workflows
  • Lack confidence in whether they are using the system correctly
  • Misunderstand system capabilities or misinterpret outputs due to gaps in system knowledge

How Learners Are Marginalized

Learners are frequently dismissed with the assumption that their struggles are “training issues” — that if they just had more instruction, they’d succeed.

One practitioner summarized the prevailing attitude as:

[Leaders] oftentimes think that it's still the idea of, ‘Well, people go to school to learn how to use our stuff, so we don't really have to worry about that part of the user experience.’

But this mindset shifts the burden of usage from design to users. While training may supplement the learning process, even great training and documentation cannot compensate for poor usability or unintuitive workflows.

If learners aren’t supported during their first encounters with the system, they may never progress to true efficiency or expertise. They will remain dependent, error-prone, and at risk of churning, or worse, transition into Legacy users who never truly master the tool.

How to Support Learners

Supporting learners requires a strong focus on initial usability and progressive learning. It’s about shortening the path from initial usage to proficient usage without relying on a formal training program to bridge the gap.

Consider the following tactics to support this group:

  • Prioritize learnability in design
  • Use inline help, onboarding flows, and just-in-time tips
  • Avoid relying on dense documentation or external training programs
  • Create safe environments (e.g., sandboxes or templates) to encourage low-risk exploration
  • Provide meaningful error messages that include actionable next steps
  • Conduct longitudinal usability testing to observe learning over time

Balancing All Three User Types

Designing successful complex applications means more than choosing whether to support novice or expert users. That question presents a false dichotomy. 

In reality, sustainable product success that delivers on business goals — from long-term user retention to reduced churn and higher satisfaction — requires thoughtful support for all three user types. Each represents a different point on the user journey, and each offers critical insights for improving the system as a whole.

Each group offers unique insights:

  • Learners reveal where onboarding, discoverability, and digital content (including domain-specific language) need improvement
  • Legacies highlight which features remain unwanted, underutilized, or unnecessarily complex
  • Legends surface opportunities for deep feature use, innovation, automation, and long-term efficiency gains

These users should not be treated as static categories. A learner can become a legend — or a legacy — depending on the support they receive and the design choices made over time. Designing for just one of these groups creates long-term risk. Supporting all three builds a more resilient, effective, and loyal user base.

By , No comments:
Tags , ,
Subscribe to: Posts (Atom)