There is no difference in B2C or B2B product UX design. Both are dealing with human — technology interaction, even that each group has specific goals and motivations. But there are significant differences in content and scale of design work.
Consumer world
In consumer world, there are no barriers between product and user. Companies are trying to make this experience seamless and remove all friction. Consumer product does not need all time visible benefitsdemonstrations. People will watch introduction video, evaluate whether product fits their needs and make purchasing decision. Good consumer product does not need documentation. Users don't have motivation to read walls of text with feature descriptions. They simply want to use it. Consumer product does not need extensive customisation. When the product does not fit their goals, they simply go elsewhere. There are hundreds of equivalents for everything.
This does not mean that benefits, documentation and customisation does not exists. But for good consumer product they are so well integrated into overall customer journey that they become invisible.
Enterprise world
In enterprise world, things are different.
But they shouldn't be.
Elements of Enterprise product experience.
Benefits
Typically it is not possible to understand product benefits and added value just by looking at product UI, not even from short product try-out. All you see is forms, dashboards, trendviews, command line windows and other complex UI elements used for input and output — there is no other content. If you don't know what the task and use case is, you have no clue why this thing is important. You need someone else to step in and explain it to you.
Documentation
It is widely accepted that every enterprise product needs stand-alone documentation. Most companies have separate tech-writing organisations that are embedded into agile teams.
Content is evolving from describing of obvious into more task and how-tooriented descriptions. Form is evolving from printed handouts through PDF's to wiki's. But the way how people consume content remains unchanged —contextual link between product and product description is missing.
Companies still force users to use two completely different interfaces to use and understand the product. The only reason is, that for companies it is easier to maintain content in wiki publishing system than content integrated directly into product.
Result is always dumb static text (with embedded pictures and videos) that does not have link to what settings are actually used in app or what options did user already tried out. Users are forced to search and dig through chapters and sections to find information related to what they are just looking at in different browser tab.
Searching for same content again and again.
It is not possible to expect that by looking at complex infrastructure monitoring tool anyone can immediately understand what is being monitored and how it works without any description.
But I like to use bike riding metaphor from @axbom article about UX Mythssaying that "UX is not about making users understand instantly how it works".
Kids can't ride bike without learning it first. Someone need to teach themhow to ride bike. But they do not learn by looking at someone else riding the bike. And they certainly do not learn by looking at video of someone else riding. They learn by using the bike itself or even better, starting with bouncycle first.
CA APM Command Center with contextual documentation integrated into core product experience.
Customisation
For enterprise products customisation means hacking. This is especially valid for technological IT companies. These are the companies, where people outside R&D are able to code their own parallel products. They can hook their hacks using API to various data sources or they can use command line scripting to automate existing features and compose them into different scenarios as they were originally intended.
User goals and motivations can be researched, synthesised and transferred into Personas. Same process has be used to identify common patternsamong large companies from different industries and synthesised into "company personas". As a result, users from banking environment can experience different try-out and on-boarding experiences than users from retail environment. There is no need to hack around one rigid set of defaults.
Input | Output
Enterprises still understand "User Experience" as fancy Apple originated term for "User Interface" design. Most designers are also failing in tangible and clear evaluation about the difference. These conversations often gets abstract and emotional.
Companies "design" Input and Output interaction components — buttons, dashboards, command lines, checkboxes. They almost always start with underlying technology before they move to Input | Output layer. Technology is explained to designer, who is then trying to wireframe these input and output elements answering pressing question of "How do we feed this component and what component we use to consume resulting data?". Along the way, trying to catch up with actual users goals and motivations.
The fancier Input and Output becomes, the better the enterprise "UX" is. You might noticed that some latest enterprise products contains ridiculous coloured dashboards, fancy data grids or abstract iconography. These are often used for tasks, where original old-school command line or table input interaction can perform better. Original problem to solve was not the feature or interaction pattern. Original problem was that users did not understand why and how they should use it and PDF's did not helped. So instead of progressive improvement of contextual input, what they got is brand new coloured dashboard and lots of new documentation.
Companies also believe that rip-and-replace old with new means innovation. But what they are attempting to do is to match Input and Output interface with underlying technology that is becoming more and more complex.
This is resulting in complex but nice and new UI's that leads to clunky user experiences, that needs more powerpoints to explain, more documentation to learn, more hacks to customise, and more people to maintain.
Product User Experience is not only Input and Output. It is the content and context that is equally important. Benefits, documentation and customisation has to be integral part of one coherent product user interface, not discrete experience touchpoints.
Conclusions
User experience does not mean that buttons are becoming better aligned on the screen. It is also not only about innovative features that product manager can think of and engineering team to code, even that they are based on better user research.
Product User experience exceeds input and output and it is not justanother abstract layer to technology and features.
Benefits | Documentation | Customisation
For enterprise products, good entry point is to start designing contenttogether with input and output, using same design methodology and craft.
Benefits does not belong to powerpoints and documentation does not belong to wiki only because they are maintained by different departments.
One coherent design driven product experience.
This does not mean that pre-sales, consultants, technical support or technical writing have to go away. But it also does not mean that they will simply join the party and throw their stuff on the screen.
It is role of UX Designer to synthesise critical product user experience touchpoints and then design the content together with respective teams.
This process will result into more integrated and coherent product experience. By removing seams between content and input|output users can do their job more effectively and even build closer relationship with product brand. To them, product is not only buttons, but also this content, its professional quality, tone-of-voice and accuracy.
Internal roles will also extend their horizons. Designing products is much more fun than designing powerpoints and wiki's ;).