I've been working for sometime now at enterprise HR solution (similar an ERP) and i've been looking for a long time for resources about enterprise UX design. Seems like it's incredibly hard to find any relevant information. For example table design - holds a lot of data, needs to support complex filtering, a lot of contextual actions, etc.
Most of the content online focuses on consumer products and the knowledge barely applies in enterprise products.
It would be great to see if you guys know any in-depth resources (preferably books).
For instance, imagine the UX of Amazon or Ebay showing you a table with all of their products. Like AMD does in this page: https://www.amd.com/en/products/specifications/processors
In short, their problem is not about table design, but how to design without a table.
In other words, think of table as a detail, as opossed to a starting point. Sometimes a table would fine, especially if it has no row variants. But if you have conditional actions across rows, or too many unused fields per row, then a table would be too difficult to implement and use.
As you mentioned contextual actions in a table, I’m pretty sure you can provide a better UX if you don’t use a table. For example, in my product I started out with a table drafting out the team members per account (invite, resend invited, remove, etc). But I ended up better by using cards. So I drafted each row variant in a card.
Do some observation and learning about how tools your users are used to do what you're trying to do.
Some resources:
https://uxdesign.cc/data-table-for-enterprise-ux-cb48fb9fdf1...
https://uxdesign.cc/enterprise-ux-anything-but-typical-a955d...
https://uxdesign.cc/tagged/enterprise
https://www.nngroup.com/search/?q=enterprise
If you have a saying, you can advocate to include those who will actually use the product.
If you are not forbidden to get in touch with them (believe it or not, some execs will forbid you to include the people you're building for in the conversation), you can try and tighten the feedback loop.
If you're designing to a rigid spec, then it pains me to say it doesn't matter: You will get paid but nobody will use your software. Those are the bitterest dollars.
The cash register has more buttons than my keyboard and that's maybe a good thing. No consumer product would do that.
However, the software contains many functionalities, for different customers. A functionality that is relevant for one customer is irrelevant for another, hence my reply on using a plugin architecture.
This clutters product. As per my other reply, one solution is to break functionality down. Keep the core tight, the rest becomes plugins that users install to solve their specific problems or a family of problems (categories).
No product can satisfy everyone and all processes and actions and be useful at the same time.
- An API that allows to interact and control your software functionality
- An SDK to allow third party development.
- A marketplace where you and third parties can put plugins/applications to your software.
One problem is clutter and trying to cram in too many things for every customer. By customer I also mean an enterprise as a whole. For every customer, only a subset of these functionalities is useful, and the rest is noise. This will be the experience of every customer using your software: mostly noise, some useful features.
The plugin architecture will increase the signal/noise ratio by allowing people to install the extensions that matter to them and only those that matter. Every customer will only have the extensions that are useful to them, and this will be the experience of every user.
Take your computer or phone. We might have the same OS, but we have different applications installed. Imagine if the entity that produced the OS wanted to satisfy us both: they'd cram the union of applications we need, and it would be a nightmare.
Our guiding line for our SDK is "Anything you can do on the platform, you can do with an API call" and "You should be able to reproduce the platform with the SDK and API keys".
Here are a few lines for a recent reply[0] to another question:
>the first few commits in our iko.ai project were to use a plugin architecture so that new features were apps/plugins we could activate/deactivate from a config file.
>These apps live in separate repositories and are loaded by the core. The core is tiny and most of the work is on the extensions. Similar to kernel vs. drivers.
>Why we did that? We've been building custom enterprise data products for almost seven years. Many of these products were so custom we couldn't sell the same product to another client if we wanted. It is not just about code reuse on the function or library level, it's "functionality" refuse as in you plug in a forecast extension, you plug in a sentiment analysis extension, etc.
>A couple of years ago, a college acquaintance came to me and asked if he could hire us to deliver a certain product. We practically had the product ready but the features were baked in the product.
>So, now, we have features as independent applications that get loaded, displayed, and interacted with easily.
[0]: https://news.ycombinator.com/item?id=24503365