CASE STUDY: CASTING PLANT SOFTWARE DESIGN

Automated Data Processing
In this article, we are going to look at the design process that produced this software.

LIVE DEMO

If you want to click around with the design yourself, you can click here .

If you find yourself confused, click anywhere on the page and anything that can be interact with will highlight itself in blue.

PURPOSE

This was designed to collected all data into a single database, streamline report generation, and track testing for lab technicians in a casting plant.

SOFTWARE THAT TRUSTS THE USER

Since we were working with experts, we didn't want to create software that would "hold their hand". They didn't need something that forced them to follow one strict procedure. They needed to change things if needed, to do the process in a different order if the situation called for it.

So we designed this to support them. It puts all the needed information upfront and let's the user accomplish any part of the test process in any order needed. If something was missing, it would notify the appropriate person without bottlenecking the process. Gone were the days of a lowly user waiting for manager approval in the software. They needed the machine to trust them, so that's what we designed.

THE MOST IMPORTANT PARTS

We had two main end users in mind when designing this: the quality manager and the lab technicians. The work order page (left image) shows all work orders in the factory and their status. Clicking on any of these takes you to a report overview, allowing details to be tweaked before generating the report with a single click.

The tests page (right image) shows you every single test. Each work order has at least four tests, and possibly more. If the status isn't "Pending", that means that there are test results, and they will appear under a test when clicked on.

The first image is the "Work Orders" page, the last is the "Tests" page.

The "Pending" filter above the tests list is important for the lab technicians, since it shows exactly what tests need to happen. Clicking on any of these takes you to the Tests Input Page, shown below. The lab tech's job is to find the corresponding part in the lab, put it through the test equipment, and review the results. If the test fails, the software automatically generates pending retests, and if there are too many failed tests it will notify the quality manager to rework the work order.

The first image is the list of pending tests. Clicking on any of them takes you to the middle image, which is a test without results. The last image shows what it looks like when a test fails.

CONCLUSION

Overall, this design replaced manual entry for lab processes, automated test creation and tracking, and dramatically reduced the time it took to create reports. This piece reflects our ideology in software development- beautiful, easy to use, and reliable. It's build for the people in the position who know how to do the job, it doesn't harm the user in anyway (frustrating software might as well cause brain death), and it gets the job done.

Let us know if you want something similar, or something entirely different. Whatever the case may be, we promise to deliver something that utterly satisfies.

Ready to work with us?

FOLLOW US



DIABASE, LLC

37975 Gilkey Rd
Scio, OR 97374

Email: peyton@diabase.io
Phone: (971) 264-0370

Made in the USA

© DIABASE 2020 - All Rights Reserved