Digital work instructions have been a hot commodity in manufacturing the last few years—a paperless, connected method replacing continually, ammended books, or rings of laminated paper work instructions. eFlex saw the potential of DWI several years ago when the market was nil. Even when I started at eFlex in 2016 there were only a couple companies that did digital work instructions, and only rudimentarily. Now there are dozens of companies who are now edging into digital work instructions.
eFlex's sales guys pushed work instructions hard—got a lot of feedback and user needs—which, in addition to visiting a few plants, allowed me to have a hand in quickly adding some great features and functionality to the current product. JEM served, first, as eFlex's digital work instructions component—providing pictures and instructions—with a direct tie-in with tasks and its process data. With the potential to allow the line operator to do this or that, and with connected, smart tools—JEM became the hub for a whole new way to do manufacturing, disrupting the PLC-driven/HMI/SCADA/MES assembly lines of Industry 3.0. The JEM hub soon became Manufacturing Integrated Platform® (MIP)—Industry 4.1. replacing the need for a huge layer of the current manufacturing process.
When I started at eFlex in 2016, JEM existed as CRUD with a rudimental UI. It was functional. A GM/Opel project in Poland was piloting JEM as it was. I was tasked with designing JEM from scratch—with no need of consideration to the rest of the app. "Design it like it is its own product."
So with an explanation of the present intent and basic functionality, the first new rendition entailed a reworking of all the existing elements—examining each function, its purpose and importance. Structuring an experiential hierarchy with an appropriate visual hierarchy.
Who will be using this interface? Line operators.
For what reason? Probably most importantly, to see work instructions. But, perhaps consider... routinely doing the same tasks, the instructions may be of secondary importance and really only needed for reference or first learning.
What's most important then? Data. Connected data. Real-time data. Interacting with data.
But it can be and was argued that work instructions are most important. Sales was for, "As big as possible." On the otherhand it was also argued, "Once the operator knows the task, he probably won't even look at the instructions any more." Maybe. More on this after other considerations. The small things also needed consideration.
The original MVP version did provide a lot of useful data. I could immediately see the benefit to the users if... if, the user could see the data. This interface was definitely developer CRUD. A lot of cool, innovative features—and functional! It was all there on the UI, but no design principles or pattern, no UX hierarchy or structure. The data —a most important element—was miniscule and heavily overshadowed by big, bold labels. This first project in Poland had the JEM screen four feet out-of-reach of operators. I don't think they would even be able to read the data. A design mess, but with all the right elements, needing a rework. Right up my alley!
Content is king! was my initial beacon. Content being the data and the work instructions. The factory environment is not foreign to me, having worked in factories in my late teens, as well as being a grip for factory photo shoots for Mascotech annual reports when I apprentinced in a design production studio. I know the personalities and I know what is shit to them. No one is going to waste time on something that is useless. It has to benefit the line operator. Actually, upon examination, it has to benefit more than the line operator. It has to benefit the team lead to be able to monitor statuses upon a glance. It has to be easy to configure for the system integrators, the process engineers, and the controls engineers. And it really should serve the C-Suite as well no matter where they are, thus allowing plant managers, CEOs and others a quick glimpse of operations and all the realtime data they need. A very complex set of requirements for a very complex process—needed to be presented simply and usefully. I like it!
First, the visible, informational data needed to be larger! Large enough to be readable from at least several feet away. The model, the serial number, the status should be clear at a glance. The timer, a progressive line across the horizontal plane was sufficient, took a minimal amount of real estate, but... seemed inadequate for what it is. If a team lead wanted to be able to view station statuses at a glance, the timer status seemed a good visual to do so. Design a new timer component to enlarge the Target Time to be legible, and make the actual time large enough to view at a glance from 10 feet away? 20 feet away? 50 feet? Circlize the timer's progress bar with the Actual Time in the middle of it pulls it all together. Add a warning threshold color so that when the progressive line meets that threshold the continuing bar and Actual Time output becomes yellow. When the time passes the set Target Time the circle bar and Actual Time output turns red. And visible from quite a distance. The redesign, a nice start.
Back to the argument of work instruction vs. data importance, assembly lines aren't like the old days where a line worker did the same exact task day in and day out for his or her entire career. Today, an automobile has all kinds of options. Color, of course. Seating. Tires and wheels. Entertainment package. Trim package. Endless options. The instructions may be pretty beneficial. Yeah, the data too.
However, not all manufacturers—not all potential customers—build such complex products. Some products are all exactly the same, or with a model shift at best. On the otherhand, some manufacturers have long takt times building complex machines like MRI and X-ray machines—and do need constant reference—and more. The example above shows the resolution—sizing handles between the data and the work instructions, as well as between image and text within the work instructions. Also the first thoughts to toggling between data and work instructions are introduced.
Immediately upon release and use, customers and potential customers wanted more than just an image upload and some text. They naturally wanted to display their work instructions on JEM. Yeah, those hideous, Industry 3.0, laminated work instructions. So aside of just allowing customers to import digital files into JEM, eFlex management was convinced JEM needed some work instruction building capabilities built into JEM. Dev found a decent open source library and I designed an interface around it. However, with feedback from customers, Sales was able to convince management how well received this function was and how worth it would be to built a custom work instruction editor (WIE).
About this time, a new competitior surfaced. Their interface looked pretty clean and uncluttered. I started getting, "John, look at this... why does their UI look so clean?" Upon examination, their app wasn't doing as much as ours. There wasn't nearly as much functionality built in. It was only addressing a single task and its information—not displaying a listing of tasks, process data, and work instruction—just a single task. Just a single task? So, my answer at the next Product Review to the above questioning was a mockup of a single-task view (STV) for JEM and a toggle between the STV and the traditional task list-view (LV) because there would also be those who would prefer and need the listing. The listing did provide lots of real-time, pertinent data. Let them decide what's important for their individual need.
It was an instant hit! The STV view was much cleaner. The LV was still right there, a click away. Sales loved it because the image was bigger. It went into development right away. It also help solidify an eFlex philosophy of putting power into the hands of the user—NOT bend them to the will of the application.
This kind of thinking—empowering the user—lent itself to another eFlex feature being developed—task events. Task events are actions triggered by an event. A sound when a task starts. A different sound and light turned on when a task is rejected. A pop up message when the cycle is completed. The possibilities are endless. And even more endless when tied to smart tools, work instructions, Node-RED and business intelligence. Power truly in the hands of the user. And intuitive enough to not really need "training".
Configuration of JEM was another aspect of UX that required different thinking for a different persona. It wouldn't be line operators configuring the tasks. Likely an integration engineer, or a process enginner. Maybe a controls engineer, or perhaps someone remotely in a corporate office. Configuration needed different thinking, yet it still needed to be pretty easy to figure out. Even with training, how often is that classroom training forgot when in actual process? Quite a bit. At first the configuration (as shown to the right), like a lot of the app was originally engineered/dev-designed, and though the target persona was engineers it still needed smoothing. Modals cut off configuration from context and requiring extra steps. There was no design styling. MPVish.
Having already set an appliction-within-application pattern with WIE and also with Andon it made sense then to begin replacing modals with that right-hand side panel configuration where possible. And instead of excessive vertical scrolling configurations, several groups of configurations were consolidated into tabs on the side panel. So now, instead of clicking a task card and having a modal covering and blocking everything underneath, a side panel just sits aside the task cards allowing configuring a task and jumping directly to another task by clicking any task card. The side panel and selected tab remains with just the content changing task to task making it extremely to flip through all the work instructions in a cycle, or to copy a set configurations to other models. This simplifies the whole process. It also keeps the context closer at hand. This would then be a prototype to shift configurations of all sorts to side-panel configuration (e.g. station options, hardware, user management).
Next bubbly forth from a weekly Product Review meeting it was put forth the concept of Events might be applied directly to JEM work instructions. Sure they could trigger a light or pop a message. Easy enough with existing capabilities. But let's push this further. Dynamic Work Instructions (DWI)! That is work instructions that are connected and react with smart tools. Imagine fastening a 16-bolt gear with each bolt required to be bolted in a specific order. The work instruction signals what bolt to fasten with a blue ring around it. When torqued down with a smartwrench if the torque is within limits the ring turns green and displays its value. Out of limits the ring turns red and a popup message displays with instructions.
I built mockups to illustrate how to simply designate a work instruction to be dynamic. How to show dynamic work instructions interactively on JEM and how to configure the work instructions to be event-driven—all pretty much with the tech we pretty much already had built in. The images below summarily illustrate this.
Again, this gives a lot of power to the user. Unlimited possibilities. And it works just like illustrated!