B2B Product UX
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 motivation. But there are significant differences in content and scale of design work.
Consumer world
In a consumer world, there are no barriers between the product and the user. Companies are trying to make this experience seamless and remove all friction. Consumer product does not need all time visible benefits demonstrations. People will watch the introduction video, evaluate whether the product fits their needs and make the purchasing decision. Good consumer product does not need documentation. Users don't have the motivation to read walls of text with feature descriptions. They simply want to use it. Consumer product does not need extensive customization. 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 customization do not exist. But for a good consumer product, they are so well integrated into the overall customer journey, that they become invisible.
Enterprise world
In an enterprise world, things are different.
But they shouldn't be.
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, trend-views, 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 in agile teams.
Content is evolving from describing obvious into more task and how-to oriented descriptions. The form is evolving from printed handouts through PDF's to wikis. But the way how people consume content remains unchanged —the 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 the product.
The result is always dumb static text (with embedded pictures and videos) that does not have a link to what settings are actually used in the 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.
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 Myths saying that "UX is not about making users understand instantly how it works".
Kids can't ride a bike without learning it first. Someone needs to teach them how to ride a 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.
Customisation
For enterprise products customization 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. The same process can be used to identify common patterns among 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 the 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 get 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 the designer, who is then trying to wireframe these input and output elements answering the 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 notice that some latest enterprise products contain ridiculously 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. The 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 help. 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 the underlying technology that is becoming more and more complex.
This is resulting in a 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 have to be integral part of one coherent product user interface, not discrete experience touchpoints.
Conclusions
User experience does not mean that buttons are 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 just another abstract layer to technology and features.
Benefits | Documentation | Customisation
For enterprise products, a good entry point is to start designing content together with input and output, using same design methodology and craft.
Benefits do not belong to powerpoints and documentation does not belong to wiki only because they are maintained by different departments.
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 the role of UX Designer to synthesise critical product user experience touchpoints and then design the content together with respective teams.
This process will result in more integrated and coherent product experience. By removing seams between content and input|output users can do their job more effectively and even build a closer relationship with product brand. To them, a 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.
