If there’s one thing I’ve learned watching engineering software evolve, it’s this: adoption follows familiarity. The user adoption process is super critical. The successful user adoption can be a decisive element for a product or technology to win.
We often assume users — especially engineers — will rush to adopt a new tool if it’s powerful enough. But the real truth? Engineers adopt what fits the way they already think and work. If it feels familiar, it becomes usable. If it demands re-learning the basics, it will be rejected — no matter how smart or promising it looks.
Over the last 20+ years, we’ve seen this pattern repeat itself. In my article today, I want to create a foundation of how to build user adoption strategies.
Let’s look at a few defining moments where user experience played a decisive role in the success (or failure) of engineering and product development tools.
File-Based Mental Models: The 1990s–2000s
In the late 1990s and early 2000s, engineering organizations were dealing with a growing mess of CAD files. Engineers organized projects in shared folders, tracked versions with file names, and emailed ZIP archives with designs labeled “final_v6_b_revised.zip”.
Then came the first wave of Product Data Management (PDM) systems — like SolidWorks PDM, AutoCAD, Autodesk Vault, and others.
These systems succeeded because they didn’t try to change user behavior too much. Instead of replacing the file metaphor, they embraced it. The UI looked like Windows Explorer. You could check files in and out, and revisions followed a familiar folder-like structure. It helped to improve user adoption for those users that struggled with files in multiple folders, but at the same time, didn’t disrupt their user onboarding, feature access and customer journey.
Even workflows like locking a file, adding metadata, or routing for approval were wrapped around the concept of a file. The tools mimicked the way people were already working — just made it more structured and searchable. That’s what made the experience usable, and ultimately, adoptable.
Had those systems tried to leap directly to model-based data or full lifecycle control at once, they would have faced far greater resistance. Instead, they won by easing users into better structure while respecting familiar patterns.
The Outlook Metaphor: How Email Shaped Early PDM and PLM Interfaces
One of the most influential user experience models in enterprise software has been the email metaphor — and more specifically, the Outlook-style interface. For many professionals, Outlook became the daily command center: documents, folders, attachments, and tracking features — all organized in a familiar layout. This structure proved so intuitive and habitual that it inspired a wave of enterprise applications to mimic it. The idea was simple: if users already understood how to navigate folders and open individual documents from a list, why not replicate that same model for other types of work?
This approach heavily influenced early PDM and PLM systems, especially in the 2000s and early 2010s. Engineering data — CAD files, specifications, BOMs, change orders — was often treated as documents. You could sort them, assign them, route them for approval, and organize them into folders or projects. The folder-pane-document-detail view felt natural, and adoption followed because users didn’t have to learn a new interaction pattern. In many organizations, training users on PLM felt like “training them on Outlook with engineering data.” It was a mental shortcut that helped overcome the initial learning curve.
However, while this model succeeded in bridging familiarity, it also inherited some limitations. The folder-centric, document-first view encouraged rigid hierarchies and reinforced the idea of disconnected silos of information. Over time, it became clear that engineering processes are more networked and dynamic than a simple document tree can represent. Still, the success of Outlook-inspired PLM interfaces reminds us that user adoption starts with cognitive familiarity — and that designing around known metaphors can make even complex systems more approachable.
I can see many PLM existing users are still deeply dependent on this user experience behavior continue to use those products for 15+ years.
Search-Centric Interfaces: The 2010s
By the 2010s, the consumer web had changed how we found information. Thanks to Google, search wasn’t just a tool — it was a mindset. You didn’t need to remember where things were stored. You could just describe what you wanted in a few words and expect results.
Enterprise and engineering systems started catching on. Several search based tools were developed at that time and most of PLM vendors were acquiring and adoption search technologies. The idea was to introduced search-first user experiences. Engineers could type part numbers, descriptions, or supplier names and quickly get what they needed — no need to click through deep folder hierarchies or memorize rigid navigation paths.
The shift wasn’t about faster access alone. It was about aligning software to how users already approached the web in their personal lives. Engineers had been Googling all day — now they could “Google” their part catalog or change history, too.
This is an important lesson: UX patterns that win in consumer tech often set expectations for business software, especially in engineering where time pressure is high and training time is limited.
Browser, Mobile, and Touch: Shaping Modern Engineering UX
The 2010s brought a dramatic shift in how engineers interacted with digital tools. What began as rigid desktop environments slowly gave way to more flexible, accessible experiences — led by browser, mobile, and touch interfaces.
The move to browser-based tools marked a turning point. Engineers could now access design data without installing heavyweight clients or syncing files locally. It enabled real-time collaboration, easier deployment, and smoother updates — a stark contrast to traditional PDM tools that remained tightly coupled to desktop installations and complex file vaults.
Mobile access soon followed. Engineers began reviewing drawings on iPads, field techs pulled up part info on their phones, and quality teams documented issues in real-time with photos. Mobile wasn’t about replacing desktops — it was about meeting users where work happens.
Yet despite this shift, core CAD and PDM systems remained desktop-bound, reinforcing a file-centric mindset that resisted change.
Touch interactions further shaped expectations. Tap, swipe, and zoom became natural gestures — intuitive ways to consume and interact with data. This simplicity forced software to shed its clutter, improving usability across roles and settings.
While browser and mobile interfaces gained significant traction in many engineering tasks, core design and data management tools didn’t keep pace. The reliance on desktop, file-based workflows persists — and with it, a barrier to broader user adoption.
This gap is more than technical — it’s cultural. Engineers increasingly expect software to behave like the tools they use every day (search, chat, mobile apps), and the systems that fail to evolve remain stuck in the past.
Now We Enter the Chat Era: What Comes Next?
And now we’re witnessing the rise of another UX model: chat-based and AI-powered interfaces.
Over the past two years, tools like ChatGPT, Claude, Bing Copilot, and others have made chat interfaces mainstream. People are typing complex questions — in plain English — and expecting coherent, useful answers.
This change isn’t just about generative AI. It’s about how people are becoming more comfortable expressing intent conversationally. Rather than clicking buttons or navigating menus, they’re starting to say things like:
- “Find me the latest revision of the motor assembly.”
- “Summarize the changes between these two drawings.”
- “Generate a procurement list with lead times under 2 weeks.”
This natural language shift is redefining the user’s mental model of what software should do. And it’s not just happening in ChatGPT — we’re starting to see AI copilots show up in tools across the enterprise stack: CRMs, spreadsheets, IDEs, and increasingly, in PLM-like environments.
Why Familiarity Still Matters — Spreadsheets and Custom Objects
Despite all this innovation, the same rule applies: if the experience feels foreign, adoption will stall. Therefore it is interesting to see how to traditional user experience is mixing with the development of AI applications. My best examples of development of GPT and Antropic Project like applications. They provide a way to embed editing in canvas, provide charts, grids and visualizations, access image editing, and many other capabilities.
This is why I believe that the combination of familiar spreadsheets and chat interfaces may hold the key to the next leap in engineering system usability:
- Spreadsheets remain one of the most universally accepted tools. Engineers use them to calculate, track, model, and communicate. Familiar grid-based interfaces help users stay grounded in what they know. Check my recent article – Excel and Human Centric PLM.
- Chat interfaces are the new front door — intuitive, expressive, and increasingly capable. Here is my article from two years ago (yes, the time flies) – PLM AI and Co-pilot catch up. The examples of co-pilots are everywhere and there is a lot for us to learn – from GitHub Co-pilot to applications like Cursor and some others.
Together, these patterns offer something powerful: a bridge between intelligence and usability.
What is my conclusion? Build for Humans First…
There’s no doubt the technology is ready. Graph-based data models, AI agents, and large language models can deliver powerful new capabilities. But unless we make these systems feel familiar — unless they speak the language of the user — they will never be fully adopted. The user adoption rates is a critical element that leads to increased customer lifetime value and ultimately increased business value and reduced customer churn.
Therefore we need to guid PLM UX designers to focus on product adoption and how easy to bring new users to the system. UX pain points and onboarding experience is key. To put a specific goal on customer adoption will support sales teams and will help to implement tools and support customer benefits. All together, building UX metrics and integrating product experience with the behavior familiar to users must be the key goal of customer success team. Measurement active users and mix with customers do with user adoption must be translated to goals of any UX engineer and developer.
PLM vendors historically focused on marketing and business value. Those things are important, but without user adoption strategies, the customer success work won’t be done properly. It comes done to communication with customers to determine the best ways for specific use case and effectiveness to achieve user adoption.
We’ve seen this before: tools that respect the user’s habits thrive. Those that demand wholesale change struggle.
As we move forward, the winners in the next generation of PLM and engineering systems won’t be defined by features alone. They’ll be defined by how well they fit the human mind.
Let’s build software that doesn’t just work — but feels right.
Just my thoughts…
Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a digital-thread platform providing cloud-native collaborative and integration services between engineering tools including PDM, PLM, and ERP capabilities. With extensive experience in federated CAD-PDM and PLM architecture, I’m advocates for agile, open product models and cloud technologies in manufacturing. My opinion can be unintentionally biased
