• 2014, ongoing
  • UX, UI, front-end

Empathy, and the ability to dive deep into the users’ mindset allowed us to transcend common design conventions, and deliver a superior product.

Designing a UI for spreadsheet-loving, information-density-obsessed engineers. How bad can it really be?

When a designer hears the words “product lifecycle and manufacturing management”, they are not exactly overwhelmed with joy. The fact is, they most likely don’t know what you are talking about.

When we got on board with Aligni, we’ve had quite a lot of research and education on the matter to do ourselves, before we could start redesigning its user interface.


This is an example of our classic front-end deliverable. A high fidelity, functional, static HTML mockup. In this case it’s a demo of Aligni’s bulk part import UI.

The most interesting part of this process was getting used to the way engineers are working with user interfaces, and how they value density over clarity. They are information processing machines who call Excel their “happy place”. The mindset switch that we had to make from “making things as obvious as possible” to “we need to fit at least 17 rows into this fold” was quite a new experience.

Our main takeaway was that Aligni is not a B2C application, and the UI requires people to learn how to use it. And that's OK.

Once this simple fact clicked, it was like a huge weight fell off our shoulders, and in fact it was a huge revelation for us. We were so used to designing for the lowest common denominator, that we completely disregarded the power users, and power users are standard here. It was a huge relief to allow ourselves certain affordances of advanced UIs.

The main challenge was:

The sheer complexity of the application by consequence made the UI itself complex. As soon as we accepted this as a simple fact, we could move the project forward much faster, and deliver a more appropriate, and finally a superior solution.

We placed a lot of importance on visual consistency in the UI. Considering the target audience, it was only logical for the UI to take the back seat, for the actual data to be able to surface.

In cases like this it is entirely possible to fall into the trap of overhomogenization of the UI, sometimes to the point of confusing users so much that they lose orientation and can’t figure out quickly which screen they are on. Fortunately we were able to utilize illustrations, and in some cases color-coded iconography in order to make things more visually interesting, and more easily identifiable.

If there is one characteristic UI element in Aligni it’s the tables. They are all over the place, and they are not always used as simple listing grids, but have various functionalities added to them. More often than not they are editable, and sometimes they contain a mix of editable and non-editable content (e.g. calculations).

This is why in 2017 we kicked-off a rogue project we dubbed “Tables 2.0”. We got an assignment to redesign a new type of table that is to be applied to a very specific corner of the app, but we wanted to see if there was a better way to handle tables throughout Aligni’s UI, both in terms of presentation, and functionality.

With tables 2.0 we wanted to see if it was possible to propagate a site-wide improvement, instead of acting acutely which would be obviously a much easier route to take.

A couple of weeks of work, a whitepaper, and a presentation later, we got the stakeholders on board, and with the help of our amazing front-end team, the new table UI is being propagated throughout Aligni, slowly but surely.