Hello<p>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.<p>Most of the content online focuses on consumer products and the knowledge barely applies in enterprise products.<p>It would be great to see if you guys know any in-depth resources (preferably books).
Hi Victor,
Books as such I can’t tell, but I’m working on tutorials on table design.<p>For instance, imagine the UX of Amazon or Ebay showing you a table with all of their products. Like AMD does in this page: <a href="https://www.amd.com/en/products/specifications/processors" rel="nofollow">https://www.amd.com/en/products/specifications/processors</a><p>In short, their problem is not about table design, but how to design without a table.<p>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.<p>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.
A lot of the underlying principles from consumer oriented design can be applied to enterprise.<p>Do some observation and learning about how tools your users are used to do what you're trying to do.<p>Some resources:<p><a href="https://uxdesign.cc/data-table-for-enterprise-ux-cb48fb9fdf1e" rel="nofollow">https://uxdesign.cc/data-table-for-enterprise-ux-cb48fb9fdf1...</a><p><a href="https://uxdesign.cc/enterprise-ux-anything-but-typical-a955da0ce7cc" rel="nofollow">https://uxdesign.cc/enterprise-ux-anything-but-typical-a955d...</a><p><a href="https://uxdesign.cc/tagged/enterprise" rel="nofollow">https://uxdesign.cc/tagged/enterprise</a><p><a href="https://www.nngroup.com/search/?q=enterprise" rel="nofollow">https://www.nngroup.com/search/?q=enterprise</a>
There shouldn't be any difference. The fact there are differences is a symptom of a broken procurement process where you get your specs from the person who has purchasing power, or an executive, or really anyone except the people who'll end up using that software.<p>If you have a saying, you can advocate to include those who will actually use the product.<p>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.<p>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.