Design System | Personas | JEM | Andon | Component-Based | WIE | DWI | STV | MIP | More Case Studies
eFlex System’s Manufacturing Integrated Platform (MIP)
eFlex Systems had been around for over 20 years when I started in early 2016. They had, primarily, one customer—General Motors of whom eFlex developed software for GM’s Powertrain assembly lines—engines and transmissions. One of GM’s executives took an early retirement, invested in eFlex and developed the next level of manufacturing software ushering in Industry 4.0 capabilities. Whereas Industry 3.0 introduced automation, computers, and robots to manufacturing, Industry 4.0, or the Industrial Internet of Things (IIoT), is about connections. Connections between smart tools and process data, between events and actions, between user, machine, and data. The Smart Factory. And eFlex was at the forefront of this. The issue was eFlex’s software was always engineer-designed for engineer users. This new software opened up to numerous users. As advanced in capability as eFlex System’s new manufacturing software was, few could figure out how to use it, even with training (unless you were an engineer). Do this here, then go there to do that, but first make sure you checked the box way over there, then come here to…
Job Element Monitor (JEM) aka Digital Work Instructions
I got hired as eFlex was launching a pilot-program for their new software at an Opel plant in Poland, Opel owned by GM at the time. My first job was to redesign a big, new feature they were presenting—digital work instructions, which eFlex designated as Job Element Monitor (JEM). JEM instantly presented assembly line operators with instructions for the particular task at hand. Prior to digital work instructions, these were typically laminated printed sheets in a book or loosely on a ring to flip through. Note: To update these rings and books, one would have to create or edit in an office, print, store, distribute to all locations and update local books or rings. Now, one change and the click of a button in an office, on the floor, or on a hammock in the Muldives can instantly update unlimited loctions. I was told to design JEM with disregard to how it and the app currently looked. Assembly line operators were the primary user, but it would also likely be configured by a systems engineer. Initial user requirements included for the monitor and its content be visible from at least six feet—and in this instance, no user interaction with the monitor as it was to be positioned on the other side of the assembly line—out of reach. But, that would just be for this instance. Seemed I pretty much had a free reign to design JEM. But free reign means designing smart and being able to justify your reasoning. First thing was to evaluate the CRUD version of JEM and the application as a whole. What did it do? What wasn’t it doing? Where were the obvious pain-points? Did the process flows make sense? And then, how to wrangle the old design into a comprehensive and cohesive whole while moving it into an entirely different design scheme? Working with the manufacturing veterans at eFlex answered a lot. A user story map unveiled unthought of items and actions.
But First, UX Goals Simultaneously, the VP of Engineering tasked me to, as a UX Designer, set my operational goals. After an initial evaluation of the application, I reported some basic style guides first needed to be set to start getting everyone on the same page, to start establishing some consistencies, and fix inconsistencies. Personas needed to be devised so we knew who we were developing for. It ain’t us. Pattern, and controls libraries needed to established, as well as, a custom icon library. I am NOT a fan of Font Awesome or any public library. It’s a lot of time looking for something that kinda fits and then is simply a contrived representation. Or worse yet, thousands of designers use the same icons, but often with differing meanings. Thus, there is little visual distinction in appearance between apps. I believe an icon should be as specific a representation as can be. It doesn’t take much time to craft an icon once designed or imagined. Over 300 custom icons I designed or adapted and crafted for the eFlex application.
In addition, I reported I would like to do as much user surveying and interviewing as I could. Also, the application really could use content-driven Help. Its current Help did little than to offer an out-dated PDF of the user manual. A user would then have to search through the PDF to find the needed section… if it was even there or up-to-date. What is needed is if you are on a configuration screen and hit the Help icon—that section of Help is displayed. And lastly, develop an innovation culture. I was turned on by Thomson Reuters' innovation culture, when I worked there, who even offered 20% of one's time spent on pushing for innovative ideas and changes. At eFlex, I came to find they were already there, allowing me the opportunity to present a lot of unsolicited ideas.
Styling I certainly needed to set some style guidelines, and eventually a design system. There were no set styles whatsoever. I surmised that one developer would create a function or screen with the libraries they knew, whereas another developer another library that they know. Being that Jira and Confluence were used at eFlex, I first created style guides in Confluence accessible by anyone—defining purpose and what elements should look like and how they should be used. This initially included a consolidation of colors and a defined color palette. To expedite fixing a large chunk of "low-hanging fruit" issues immediately, I create a Quick Fix document to quickly fix obvious issues and instantly give the application a more cohesive look. These style guides would then serve as the foundation for an atomic design-based design system—of which the developers then fashioned to create a Living Style Guide built right into the application. Everyone, new and old would be working from the same blueprint now.
"John," my boss called from the conference room, "Design me an Andon board." "Okay," I answered like I knew what he was asking for. "Siri. Andon board."
Upon researching Andon boards, they are those big, ugly LED signs above the factory floor that displayed this or that data, often OEE data, but also parts built—good and rejected, or some other manufacturing-related key performance indicators (KPI). Very limited to what you can display. Did I say ugly? And very expensive?
I wondered and asked myself why an Andon board had to be one of these prehistoric, ugly, LED boards. I mean for a fraction of the cost I could buy a huge hi-res monitor and jack whatever I want on to it.
Component-Based Manufacturing, Industry 4.0 Style
About this time, eFlex got a big contract from Navistar to install the eFlex application in a new assembly line at a plant in Springfield, OH that Navistar was currently integrating to build utility vans for GM. The eFlex System to drive this assembly line from a frame placed on the line to driving-out-the-door operation. That is, telling each station along the line what their task is for each particular vehicle. And error-proof the tasks are done correctly. The big challenge here was eFlex’s app had always been model-based, that is, basic manufacturing assembly—engines, transmissions. Not a lot variance. Just model variances. However, what Navistar needed was a component-based system—with LOTS of variances—model, engine, color, tires, wheels, upholstery, entertainment system, and countless options. That was more than a bit tricky. This began in late September. They wanted things to start rolling in February. We had four developers, a couple of project managers, the stakeholders and one designer, me. Off to the races.
I had a lot of configuration and process flow considerations,while at the same time learning all the intricacies of lean manufacturing, the intents of the eFlex application, where the app is now deviating, while brainstorming with the team to the steps forward. BUT, if we got this right, this opened up eFlex Systems to all kinds of potential customers. Imagine! Imagine receiving a numerical string from GM. This string represents everything for a particular build. For an individual vehicle. An abbreviated Bill Of Materials (BOM), so to speak. The eFlex application takes this string, received directly from GM’s enterprise resource planning (ERP) system, translates it to then instruct each station along the line what its tasks are for each different vehicle. eFlex then error-proofs the tasks were done correctly, collects, stores and distributes process data, then moves the part to the next appropriate station. Now, multiply that by several hundred a shift. Did I mention this had to be easy to configure too? So, how do we make this easily configurable? What are the process flows? There are a gazillion moving parts to consider and juggle here! Lucky I work with some people who know their manufacturing grits. After lots of going back and forth we worked out a relatively easy way to manage the complexity of this task, including the ability to manipulate the build information once in the system—adding, editing, and deleting components separate from the BOM.
On the heels of the Navistar project, Faurecia came to eFlex with a component-based project, too. Not vehicles per se, but center-components for Ford Explorers and Navigators. Very similar in component-complexity with a wide array of options, but with a different scheduling source. A matter of adaption. GE Healthcare soon after became a big, new customer installing our system in factories around the world, manufacturing such things as MRI machines, X-ray machines, and incubators amongst other high-end products. Nissan had projects, and Flex-N-Gate started using the eFlex System application. And each had their own requirements that eFlex was mostly obliging. However, the big thing that Sales was saying they all want and are asking for is—better work instruction capabilities. My sentiments exactly! I only need a little encouragement to start cutting loose.
The Work Instruction Editor (WIE)
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, even if it were just their 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. My role was to design such an “application-within-an-application.” And there was a lot of opinions and lots of requests, from dev wanting to utilize open source libraries, to sales happy to copy Powerpoint, "They know Powerpoint," to me advocating for a more Photoshop or Sketch type of behaviors. “Oh yeah, and make it so the work instructions go through an approval process… oh, but someone else may need to be the deploy person… oh, what if a different work instruction shows if there is a reject… it may be used in multiple tasks... we need to call up specific pages from a PDF...”
Dynamic Work Instructions (DWI)
Using the above configuring example, let's now take digital work instructions a step further and examine the concept and execution of dynamic work instructions (DWI) more fully. The above mockup shows a dynamic work instruction as it's created in the Work Instruction Editor. Once created it's accessible to be imported into any number of tasks. And being a DWI each ring (created dark gray) around each bolt is an individual dynamic object, as is the "Big Mistake!" text box—all—hidden upon the start of the operation—but revealed or initiated by events such as a rejection due to over-tightening. At the start of, say, a Torque Task, all the dark gray rings remain hidden until the current bolt is called in which a ring colored blue is shown on the bolt to first be fastened. Or, at start all the rings turn yellow revealing all the bolts that will need torquing. Either way, when a bolt is torqued within its upper and lower limits, the ring turns green—and optionally, the value could be shown aside the torqued bolt as it does in the task list. The ring turns green and the next bolt gets a blue ring. If a torque is lower or higher than its configured limits, the ring turns red and the "Big Mistake!" banner shows. In addition, any number of other events can easily be configured—a different work instruction shows after X-minutes, a fog horn blares three times, an Andon warning light glares, the station monitor whispers in a French accent, "You're in trouble," while a hologram of Chuck Barris banging a gong appears in the aisle next to the station.
“Why are their work instructions so clean?"
At an Assembly Show in Chicago, I was wandering around, came to a booth that looked like they did work instructions. The interface very .NET-looking, dated. As I was checking out one of the videos a salesguy approached and greeted me, looked at my badge and asked, “What’s eFlex Systems do?” I replied pretty much the same as you I think. “Tell me more about your product,” I followed with. He quickly lost interest in talking to me, saying, “My guys are doing the same thing.” “What’s that?” I asked. “Scoping out the competition.” I really wasn’t, but probably a good idea. “Who’s the competition?” “So-and-so over there across the hall… oh, and them right there, they're new.” So I went to the booth of them right there. They had a nice looking product. And after me standing there for a couple minutes, one of the guys from the booth gave me an unsolicited, 20-minute demo. One of the founders, actually. Afterward, he looked at my badge, “What’s eFlex do?” Later, I had mentioned to my boss and the salesguys at the booth about this competition. They had been unaware, but was definitely now on their radar—as we were now to they. The next week during my weekly Product Review meeting, our new competitor had been a topic of discussion amongst us, most technical, but I got hit with, “Why are their work instructions so clean? I mean look how big the picture is, and just a couple big buttons…” After the meeting I researched what I could find of their work instructions. When I found some images, it was readily apparent they were displaying only one task with just scant process information. Yeah, one task and sure the image can be much larger and cleaner. Our work instructions showed a list of all the tasks in a present operation—which is very useful to probably most users. However, some users it may be more beneficial to have a larger image. “As big as possible,” the salesguys constantly pleaded. I thought, why one or the other? ("Let the user decide," said a French accent in my head.)
JEM Single-Task View (STV)
So before the next Product Review, I designed and mocked up a toggled option from the current List View (LV) to a Single Task View. The STV displayed ONLY the process data for the task at-hand, allowing me to narrow the left-panel a great degree, thus giving more real estate for the work instruction image. In addition, if the user wanted more image, a full-screen option was also included, or they could option off the timer panel. Next and Previous arrows allowed the user to go back to check a value or status from a previous task, or if needed to step forward to see the tasks ahead. All the LV features and functionality were redesigned into the STV. At the next Product Review meeting, I mentioned I looked into why their UI looked so clean and explained they were displaying only a single task. Then I showed my mockups. Blew everyone away. Its priority skipped ahead of everything, and with some minor design and configuration tweaks went right into development, and into the application.
We were all starting to get into the mindset of giving as much control into the hands and ingenuity of the user—with the application becoming a platform of manufacturing tools, processes and functions. Even more new customers, large and small, were checking out and piloting the eFlex Systems application. Snap-on Tools, Whirlpool, Delta Faucet, Panasonic, Universal Electric, Tigercat, Komatsu, even a company that makes metal wallets. The fact that tons of process data was now easily accessible for and from all kinds of actions is very appealing. Sales was also devising new ways to offer the application in varying levels, eventually a three-level SaaS offering. I was involved in several Marketing meetings to mold and craft the application, and its functions into a manufacturing platform, eventually becoming the eFlex Systems Manufacturing Integrated Platform (MIP).
eFlex System's Manufacturing Integrated Platform Comes To Life
As more and more features, functions, and application-in-applications were being designed, developed, and put into production it became quite apparent we now had to nicely wrap this all up into a cohesive unit. As a marketing team (stakeholders, sales, marketing, design) we wrestled with ways to present this. Is it an app with various modules? Or checkbox features? Do we push manufacturers into a SaaS mindset and practice? In the end, it was pretty much agreed upon this was more than an app with a lot of features.
What we were putting together was actually a platform. It was apps. It was features and functions. It was tools. It was accessibility anywhere on anything—station monitor, tablet, smartphone, even a smartwatch if you want it. And it was designed for the user’s preferences. Not just user-friendly, user-centric, this was a platform to allow the user to use these tools, these functions, these apps and create workflows that suit them—not us forcing various manufacturing users to work our way.
By the time COVID came around, the eFlex Systems Manufacturing Integrated Platform was pretty solidly set. Not just with UX and UI roadmaps, but also in the way the platform was being developed—more as a cohesive whole. Also in the way marketing was presenting it, and Sales was licensing it. It was impressive. And bootstrapped all the way. Where competition was targeting huge investments to get on the field, we were there. And our customers were benefitting as well, with more parts per hour, reduced cycle times, and a marked increase in production—all providing huge annual savings.
Upon getting to this point, there were also numerous other features and epic stories conceived, designed, and developed:
eFlex Systems is a great place to work. No micromanagement. No looking over the shoulder while working. No harping as to when is this going to be done. No do this do that. As long as you put in your eight hours a day, made all necessary meetings, scheduling was quite liberal. It amazes me the complexity of this application and what it does. It always amazes me as to what this small group of developers (4-10) produces. Plus ownership—the shareholders—really know their domain, each with over 20 years in real-life engineering and manufacturing.
This is probably the most laid back job I’ve ever had. Laid back not meaning doing little, but laid back in everyone knew what they had to do and did it. After being furloughed due to COVID-19, I was checking my Trello board for something—and realized I was currently juggling A LOT of stories in various phases. Four stories in To Do, a channel for items I don’t want to forget, but not whatsoever urgent. 29 Stories in the Design channel, stories I’m currently working on designing, a lot of these stories are ideas or concepts of mine being developed in spare chunks of time. 107 Stories in Review, things designed awaiting design review by shareholders. 121 Stories in the Development channel, things approved by shareholders, awaiting or in development. 261 Active stories. Plus 182 stories in the Story Done channel, these are things completed and developed into the platform.
My Trello represents my eFlex UX stories in various stages for about the last 2-1/2 years—after much of the highlights I already touted above. These are stories from slight enhancements to full-blown app-in-app epics. Most of each story—I've written the story, handled the UX and UI design, and worked with shareholders, project managers, and development—concept-to-completion. Laid-back, but certainly not idle ;-)