Ask HN: Does anyone know any good resources for enterprise UX design? | Hacker News Reader

Ask HN: Does anyone know any good resources for enterprise UX design?

13 pointsvictorbojica13 comments

Hello

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

View on HN

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

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.

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/enterprise-ux-anything-but-typical-a955d...

https://uxdesign.cc/tagged/enterprise

https://www.nngroup.com/search/?q=enterprise

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.

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.

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.

It's not really about what you put in your product, but more of how you design your product to accommodate all the data, actions and processes required for the people to do their job and not look or feel like accounting software or some oracle tool

What you put in your product is indissociable from how you design it to accomodate users. As per my other reply, the problem is wanting to accomodate all users for all the data, actions, and processes.

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.

The users.

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.

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.

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

It's hard when the sale process is about a year. The sample size is way too small and we'll probably end up developing a one-customer product... Not saying that it doesn't help, but you need more users

Enterprise pricing reflects the fact that it's hard. It reflects the fact that the sample size is small. It reflects the fact that the products are bespoke to a single customer.

Reply on news.ycombinator.com