Designing AI Software for Manufacturing

Designing AI software for manufacturing is not the same job as designing a SaaS dashboard for an office team. Your users walk the floor, think in shifts, and have about ten seconds between other problems to look at your product. If it does not tell them what to do, they stop looking.

If you are an AI startup selling to manufacturers, you probably have strong models, a few pilots or design partners, three to six people, and no designer. The product works technically. The question is whether the people on the line use it, and whether the people at headquarters believe it is worth a rollout.

I was the founding designer at Almetra AI, a computer vision company for manufacturing, from the first prototype to a $19M Series A. Along the way I interviewed manufacturing teams, ran tests on the floor and walked production lines, including at IWC and ABB. This guide is what I learned about designing AI products that factories actually use.

The short answer

Good AI software for manufacturing does four things:

1. Gives answers, not data. What is wrong, where, and what to do next, in plain language.
2. Follows the rhythm of the plant. Shifts, handovers, today and yesterday.
3. Focuses on the bottleneck. The one station that limits the whole line.
4. Earns trust in the model. Evidence behind every insight, and an easy way to push back.

Everything else is detail. Most of the mistakes I see come from treating the factory like an office.

Who you are really designing for

In a factory deal there are usually three groups, and they want different things.

Line leaders and shift managers use the product every day. They are responsible for output on their line, they are busy, and they are rarely at a desk. In our research at Almetra, the pattern was consistent: shop-floor managers do not have time to analyze dashboards, and when they do look, they only care about today and yesterday.

Plant and operations managers care about how the line performs over weeks. They want to see whether problems get fixed and whether the improvements stick.

Headquarters (operations leadership, digital transformation, sometimes IT and procurement) decides whether a pilot becomes a rollout across plants. They may never touch the product on the floor, but they see it in reviews, demos and slides.

Your product has to work for the first group and convince the third. If you only design for headquarters, you get a beautiful analytics tool nobody on the floor opens. If you only design for the floor, the rollout stalls because nobody upstairs can see the value.

Mistake one: shipping a dashboard and calling it a product

Almost every industrial AI startup starts with a dashboard. That makes sense. You finally have data nobody had before, and a dashboard shows it.

At Almetra, version one was exactly that: the main KPIs at a glance and powerful filters to find bottlenecks by product, day or station. It looked great in demos. But in the hands of line leaders, it took time to analyze and gave no clear next step. Lots of data. Now what?

The fix was not a better chart. It was a different job for the product. We moved from charts to answers: each station got one column with its key KPI and at most two insights in plain language, saying what is wrong, where, and what to do. The analysis moved from the user to the product.

If your product today is mainly a dashboard, ask one question in every pilot: after looking at this screen, what does the line leader do differently? If the answer is “nothing yet”, that is your design problem, not your model problem.

I go deeper on this in SaaS dashboard design for enterprise buyers.

Design around the shift

Offices run on weeks and quarters. Factories run on shifts. That changes a lot of design decisions:

• Default to now. The first screen should show the current shift, then today and yesterday. Long-term trends belong a level deeper, for the plant manager.
• Show when things went wrong. A daily average hides the 40 minutes where a station stalled. At Almetra we added one small pill per hour, so you could see at a glance when a problem happened, not only that it happened.
• Design the handover. The end of a shift is one of the most important moments in a plant, and it is usually a conversation, a whiteboard or a spreadsheet. We rolled everything into one shift report: a short summary, the main KPIs and the insights worth keeping, ready to share with the next shift.
• Be honest about unfinished numbers. Data that is still coming in should not look final. We showed a question mark instead of a value that would change later. One number that silently changes after someone acted on it can cost you the trust of a whole line.

Focus on the bottleneck

A production line is only as fast as its slowest station. That sounds obvious, but most interfaces treat every station and every metric as equally important.

When you design around the bottleneck, the product gets simpler and more useful at the same time. Rank insights by impact on output. Make urgency readable without reading: at Almetra we used four insight types, so the icon alone told you how urgent something was. Push everything that is fine out of the way.

A good test: show the main screen to a line leader for five seconds, then hide it. Ask where the problem is. If they cannot tell you, the screen is too loud.

Make the model trustworthy in the UI

Factory teams have seen plenty of software promise a lot and change little. AI adds a new risk: if the model is wrong a few times without explanation, people stop listening.

Trust is mostly a design problem:

• Plain language. “Station 4 is slower than planned since 10:00, check the feeder” beats a confidence score and an anomaly chart.
• Show the evidence. Every insight should link to the data or footage that backs it up, one tap away.
• Let people push back. At Almetra, resolving an insight took a tap, and that answer fed back into the model, teaching it what is worth flagging. Users see their input matters, and the product gets better.
• Design every state. Empty, loading, error, no insights, shift change. A blank screen at 6am looks like a broken product. We built the design system on shadcn/ui and covered every component in every state, light and dark, so engineers could ship the designs as they are.

Test where the work happens

You cannot design manufacturing software from a desk. The most useful sessions I ran were in context: following a line leader through a shift, interviews on the floor, and thinking-aloud tests with real prototypes.

A few practical notes:

• Plan around shifts and plant access. Sessions are short, and the line comes first. Book them like you book a customer visit.
• Test on the real device. If they use a tablet on the floor, test on a tablet on the floor, with gloves, noise and bad light if that is their reality. Almetra’s product ran on iPad as well as web.
• Map a day, not a screen. Draw a line leader’s day from first walk to end of shift and mark when they would open your product. Design for those moments.

Design for the rollout, not only the pilot

Pilots in manufacturing are won on the floor and lost at headquarters. Once the line uses your product, someone has to explain to people several levels up why it should go to ten more plants. I wrote a fuller guide on designing enterprise pilots from POC to contract.

Help them with design:

• A shift report or summary that travels. If a plant manager can forward something clean to their boss, your product sells itself internally.
• A sales demo that shows the floor. Executives will not visit the line. Your demo should show the moment a line leader sees an insight, acts on it, and the problem goes away. Here is how I approach designing a sales demo for enterprise SaaS.
• A product that looks enterprise-ready. Large manufacturers buy from companies they believe will be around in five years. A consistent, calm interface signals that. More on that in enterprise-ready UI for AI startups.

The outcome at Almetra was a $19M Series A and a product that now serves $1B+ companies. Design did not do that alone, but it helped the team figure out what really matters to the people on the line, and made it easy for engineers to ship.

A quick checklist for your next pilot

Before your next plant pilot, check your product against this list:

• Does the first screen show the current shift and the biggest problem right now?
• Can a line leader tell what to do next in under ten seconds?
• Is every insight written in plain language, with evidence one tap away?
• Can users mark an insight as resolved or wrong, and does that feed the model?
• Are empty, loading, error and shift-change states designed, not left to chance?
• Is there a handover or report that someone would forward to headquarters?
• Have you tested it on the real device, on the real floor?

If you answer no to three or more, the product is probably holding back your pilots more than the model is.

When to bring in a designer

Most manufacturing AI teams I talk to have the same setup: strong engineers, a working model, first pilots, and a product that grew out of a dashboard. That is fine for getting data flowing. It gets expensive when pilots need to turn into rollouts and the product has to work for people who never asked for it.

That is the moment a founding designer pays off: someone who goes to the floor with you, turns research into a clear product, and builds a design system engineers can ship from. If you are weighing options, I compared a founding designer vs an agency here.

If you are building AI for factories and want a second pair of eyes on your product, that is exactly the kind of work I do at Grauberg.