
Ask HN: Does anyone know any good resources for enterprise UX design? - victorbojica
Hello<p>I&#x27;ve been working for sometime now at enterprise HR solution (similar an ERP) and i&#x27;ve been looking for a long time for resources about enterprise UX design. Seems like it&#x27;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).
======
efortis
Hi Victor, Books as such I can’t tell, but I’m working on tutorials on table
design.

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](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.

------
this2shallPass
A lot of the underlying principles from consumer oriented design can be
applied to enterprise.

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/data-table-for-enterprise-ux-cb48fb9fdf1e)

[https://uxdesign.cc/enterprise-ux-anything-but-
typical-a955d...](https://uxdesign.cc/enterprise-ux-anything-but-
typical-a955da0ce7cc)

[https://uxdesign.cc/tagged/enterprise](https://uxdesign.cc/tagged/enterprise)

[https://www.nngroup.com/search/?q=enterprise](https://www.nngroup.com/search/?q=enterprise)

------
Jugurtha
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.

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.

~~~
anotheryou
What about easy peasy vs power users?

The cash register has more buttons than my keyboard and that's maybe a good
thing. No consumer product would do that.

~~~
Jugurtha
That's at the functionality level. You have the common parameters or settings,
and then the advanced ones.

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.

------
brudgers
The users.

~~~
Jugurtha
Yes. As per my previous comment, there are unfortunate situations that prevent
this.

    
    
      Developer -                                        - User
                 \                                      /
      Developer -----> Vendor Rep <---> Client Rep ---||-- User
                 /                                      \
      Developer -                                        - User
    
    

The || represents a barrier/broken link. The users are involved once the
product is "finished" and told to start to use it. This is a great way to
build useless products.

~~~
victorbojica
We do have a saying, as our product does a lot of atuff differently than
competition and our users accept that (they're even looking for that). we also
decided that we're not going to become a one customer product, but even with
feedback and previous domain experience, it's still hard to model an
enterprise product that accommodates all the required processes and data and
still feel good and not feel like accounting software.

~~~
Jugurtha
One way to solve that is with a plugin architecture and categories and a
platform. You can create:

\- 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](https://news.ycombinator.com/item?id=24503365)

