HOME | BACK
Background Image
Application reDesign
& Evolution


Next Arrow
JEM | PART HISTORY REPORT | PLANT CONFIGURATION | LIVE PLANT | USER MANAGEMENT

A Great Idea, "A Gamechanger"... But Other Than The Developers, Who Knows How To Use It?


A part of my interview process at eFlex Systems in 2016 entailed designing a work instruction monitor UI for guitar manufacturing. Several weeks later, after I was hired, my first big task—redesign "JEM." JEM, an acronym for Job Element Monitor, or digital work instructions, being a new addition to eFlex's manufacturing software package. (Coincidentally, the JEM redesign ended up not much different than my interview exercise.)


eFlex had worked with GM for over 20 years, developing software for assembly lines. One of eFlex's owners was a former executive at GM and was now developing the next evolutionary stage of manufacturing software at eFlex. A gamechanging product for manufacturing—ushering in the Industrial Internet of Things (IIoT). Not a new concept—but new methodology. Problem was it was somewhat difficult to understand.

This was in large part an engineer/developer-designed application with a sprinkling of different designers at different times. A lot of different patterns. The UI was CRUD and a lot UX jumping through hoops. Much of the configuration was disjointed, some pieces of necessary configuration being in one place, the next step someplace entirely different with no direction (except for mention in training). There were certain things that were required before other things and no logical or intuitive process. Buttons were all over the the place. Each element vying for attention.

It was very functional. It added a lot of innovative features. And the potential was serious. However, it required training. And retention because there was little further documentation. In addition, the UI was assembled with no consistencies, alignments or pattern. Pre-MVP-like. CRUD.

JEM

So with the mandate to redesign JEM, I was also told, "Don't worry about the current app design, design it as if it is its own product." That helped tremendously. After initial, preliminary research—who uses this product? how? why? what is expected of them? what do they expect of the product...—I took the same elements and functionality, and presented a new UI design—with an easy-to-read interface, a visible cycle timer, larger-target buttons, and a darker interface for less eye stress. It also included an adjustable task list/work instruction window. If in operation following the "tasks" is more important the list can be widened, whereas if it's important to have work instruction detail, the image area can be widened to enlarge the image.

Soon after I was hired, eFlex Systems also hired a Marketing Director and VP of Sales to further round out the team. A sales team grew, touching a lot more customers and prospects getting great feedback as to what is being looked for in manufacturing software. One of the things Sales constantly asked for was "larger work instructions... as big as possible..." Sure the image is important, but so is the data. Can't have it all. But there could be a good compromise!

The data is important, especially realtime data for the task-at-hand. At this development layout, the left side had a "list" of tasks showing the "task-at-hand", as well as the previous tasks and their statuses, and a preview of the upcoming tasks. Important. But it does restrict the size of the work instruction. Also important. What if we left it up to user to decide what's more important? Sure, they can adjust panels to make the work instruction larger but it truncates a lot of the data—on all the tasks. On all the tasks! Would the space be there if it were only the data for one task—the task-at-hand?

In 2017, I mocked up and presented the concept of toggling to a Single-Task View (STV). The idea was well-received and soon implemented.

Soon after, I was shown one of eFlex's clients utilizing pencil and paper, and hourly manual inputs to record hourly production counts (e.g. good, rejects) on a clipboarded sheet of paper, in which then an anaylst once a week records all the manual inputs into the computer for operational anaylsis. My boss further explained our system already records this info. Tie it in with scheduling and we have it all right there on screen. No manual inputs. No paper. Add Business Intelligence (also at the time being developed) and the analysis is available realtime. Tie in operational buttons and we have a very useful OEE screen tied directly to and toggled from the current JEM station screen. And so I designed the OEE screen.

JEM also became the hub for a whole new conceptual approach, soon to be trademarked Manufacturing Integrated Platform (MIP). MIP evolved a feature called action events. Action events allowed different things to happen driven by different actions or events. For example, a red light being turned on when a part is rejected; or an appropriate pick light being turned on to indicate which part to choose depending which model—are traditional types of action events traditionally driven by very expensive PLC-IO connections.

Aside from already doing this within MIP, these types of event actions can now be applied in a wide variety of ways—show a different work onstruction for Start, for Pass, or for Reject; when this task starts if it is Model A show this AR guide, if Model B show that AR guide; or, Dynamic Work Instructions (DWI). DWI being work instruction action events that interact with the connect tools. For example, a task to torque down a 16-bolt gear in a specific order. The work instruction lights up the current bolt on the work instruction with a blue ring. If correct torque, the ring turns green and the next bolt gets a blue ring. If the torque is outside its prescribed limits the ring turns red and a message appears. The possibilities are limitless.

A built-in Work Instruction Editor (WIE) also developed very quickly from an open-source library to a fully, custom-designed editor—to give the ability to create work instructions within the MIP environment—and lead the way to create work instructions in a new, more useful way.

Customer feedback and requests also led to utilize JEM in several ways not conceived at its inception including a hand-held layout for integrated use with barcode scanners, and more.

I was privedged and given a lot of opportunity in varing degrees with different features of this evolution. The look and feel of JEM then evolved into other screens: JEL (JEM's little brother), Andon, Business Intelligence, even smartwatch designs. This JEM-look currently serves as the roadmap for the entire app transformation.



Part History Report

The Part History Report is meant to be one of the more widely used pages on the app for a wide range of reasons—but it was hard to quickly comprehend, and it was clunky. There was the intended "drill-down" functionality of the data, but it was a continous scroll of serial number/station/tasks/process data, then scroll down to the next set. Large amounts of tasks or process data always disconnected the user from its source, "What station is this again? What serial number am I on?" Imagine a single serial number goes through a dozen stations. And in each of those stations there are 1-20 tasks. And a pertcentage of those tasks each bears process data. That is a lot of scrolling and searching—especially if you are looking for a single piece of data from a particular task at one of any number of stations. Very easy to miss what you are seeking.

So instead of vertical-scroll-thinking on the horizontal plane, what about some vertical thinking and look at the horizontal plane?

That is, instead of stacking the data in continuous chunks, make three panels side-by-side. First panel list all the serial numbers. When selecting a serial number the second panel displays all the stations that serial number went through. Select a station. The third panel displays all the tasks for that serial number at that particular station. Icons indicate if a task bears process data and clicking the icon displays a modal with the process data for that task, in that station, for that serial number.

This makes it very easy to see a list of serial numbers, spot a reject and immediately drill down to the rejected task. Click, click, there it is.

Content Is King!

One of the things I remember well from a previous boss was him saying, "Content is king." What he was referring to I don't recall, but in communications—content is king. This led me to looking at data differently and how it almost always is presented—bold labels and subordinate content—and usually with a subordinate weight and smaller font. This seems to me—BACKWARD! Labels and headers are meant to lead you to the content you seek, then should fade away—not constantly poking you in the eye or needlessly vying for your attention.

It was at this point when I started pushing a "Content Is King" philosophy, reversing the common practice. I started making labels and headers subordinate to the content not only in data grids, as shown, but also and especially in configuration forms.




Plant Configuration

The Plant Configuration is the most important function of the app. With this you layout all the areas, groups, stations and tasks. This is where you start... or you should... or so it seems... anyway there was a lot of clunkiness here, even in training. "You want to do this, but first make sure you go here, and when you are done here click the return key—I know no indication—otherwise nothing is saved..." It took me a long time to get the process down intuitively without fucking up.

I would wager from the looks and process this is a case of "MVP-syndrome." That is, "Okay let's first worry about getting this functional... MVP it then we'll come back around and clean it up." MVP, that is minimal viable product, works great when it is part of a strategic plan and does get cleaned up. But often "cleaning up" if not done right away becomes a lot of work—especially if additional screens are added or complexity is heaped upon it.

That in large part is the case here. The app still bears the original right panel look and mechanisms, even though a design-makeover—seemingly simple to me—was presented soon after I started at eFlex. Reason being it hasn't been updated is there is a lot complexity involved and if we are going to do that thing in the future then let's do this then. And of course, "it is functional as is," and "there are more pressing matters.""

We did clean up the workspace a bit though! Changed a multitude of content-blocking configuration modals to configuration side-panels interactive with the workspace and task cards.

That Thing

Back when this development was originally MVPd, technology was different, not so advanced, developers were not as experienced with the newer technologies now behind this app, the app wasn't yet fully defined—and it was done as it was for all the right reasons at the time. But time changes things, and so must one evolve to be innovative, and to stay competitive, or not. So with an eye on evolving technologies and a better understanding of the needs of our now diversifying clientele, I looked at this whole plant configuration mode from a full user-perspective... as I should. Damn the developers. Just kidding. Kind of.

After working at eFlex for awhile I've seen a few plant layout schematics showing layout and how parts and product flow through it. And with a diversing clientele, it's apparent all users are not the same and not all users will want to do things the same. So when discussing or planning stations, such as Station 1 in regards to its operation and relation to where the part goes next if this or that—it seems to me not all people can float all these relationships and positioning in their heads and choose the right choice with dropdowns and such. However, drag-n-drop visualization may be the answer for the majority.

What I thought through and presented was a method, using existing technologies, to create a visualized, drag-n-drop plant configuration—styled with the same patterns already developed elsewhere in the application. The overall look-n-feel pattern developed with JEM. The application-in-an-application pattern of toolset on the left panel, configuration on a right panel, workspace in the middle used on Andon and WIE, drag-n-drop from Andon. And connecting nodes used in Node-RED.

The idea is from the left panel first select the AREA tool and drag area shapes on to the workspace, resize and position them. Configure them on the right panel. Then within the areas place groups, if further subdivision is needed. After, drag-n-drop stations into place. Set prerequisites, that is what station a part goes to next, by dragging a node from one to another sets that prerequisite. All quick and simple. And, very visual!

The plant configuration can be laid out exactly like the physical floor making references much clearer—removing lots of ambiguity in concept and reference. See the flow. Click any station for its configuration on the right panel. And, if we added a Live Plant toogle...




Live Plant

Live Plant is a visualization tool containing what parts and their status is in each station and buffer. A very handy feature, however you had to click each station or buffer to get this info, or to even find out if anything at all was in the station. Though functional and handy it was still clunky and MPVish.

This was one of the first tasks I was given, soon after the JEM design and I had not yet settled on an overall application evolution process. However the one thing I thought helpful, displaying the amount of parts within the station and its buffers upfront without clicking. Total amount and breakdown of Good and Reject parts. One still had to click to see what serial numbers were listed within, but could then click it to view its entire part history.

The new Plant Configuration mode led to the thought that a single toggle click could should display a vibrant, Live Plant view—all with the same features and functionality—but in the more realistic layout.


User Management

The original User Management page is obviously MVP. All the user profiles were available to all the other users. It was clunky. And used an uncommon pattern. But... it worked. Good enough for now. But come an onslaught of new, diverse clients, now is now over.

The makeover here was really quite simple. Two views. An Admin view which shows all the users and allows admin to also add, edit or delete all users, whereas a user without admin status would only see their own user page.